When this happens, it will be shouted far and wide. It’s something we’d all like to see.
3 Likes
@PDXTabs:
That worked; thanks!
@Petr_Sedlacek:
“The proper solution is probably a fix for the sensor-hub kernel module to make both the auto-brightness sensor and the Brightness Up/Down keys work at the same time.”
Hah, aye, but that is far beyond my coding abilities. 
And since I want the brightness control keys much more than I want the auto-brightness sensor, I’m quite glad to have found at least a workaround for that here. 
“If the fix is implemented in the kernel module, it will take quite some time to get to the kernel package in your distro, and it will very much depend on the distro. But the fix should eventually come with the kernel package.”
Ah, thanks.
anyone seen issues on this with the current F37 updates?
Linux 6.1.7-200.fc37.x86_64 and i’ve just noticed the brightness isn’t working anymore. It was fine this morning. Blacklist entry still exists nad has been working fine for months. Reboots aren’t fixing it (which is about as far as i’ve got with it tbh!).
Manual brightness via KDE’s Battery & Brightness icon (lower right) works fine.
Is it just me?
I’ve encountered the same issue and fixed it, by setting acpi_backlight=video in the grub config (and running grub-mkconfig again, of course).
Right before it stopped working, and before the kernel update my acpi_backlight was set to vendor.
3 Likes
sudo echo “blacklist hid_sensor_hub” > /etc/modprobe.d/framework-als-blacklist.conf
sudo update-initramfs -u
(reboot)
Fixed it for me, it also fixed the media keys
this is flapping for me.
applied the acpi_backlight=video via grubby sudo grubby --update-kernel=ALL --args="acpi_backlight=video" within a few hours of @Dennis_Wolf’s comment.
F37 6.1.7 kernel came out and brightness keys stops working again. confirmed this setting is still present, so removed it sudo grubby --update-kernel=ALL --remove-args="acpi_backlight=video". reboot & starts working again.
now after another reboot with 6.1.7, it’s stopped working.
are you guys seeing it being intermittent like this? I’m currently wondering if theres a race-condition or detection bug thats causing it.
It is broken again for me - input: FRMW0001:00 32AC:0006 Consumer Control was showing up on Linux 6.1.6 but not on 6.1.7 or 6.1.8.
edit: actually it seems to be flapping for me as well. I recall a few days ago adding i2c_hid_acpi seemed to fix it - but now I removed it and rebooted and Consumer Control is back. So it’s probably not directly related to i2c_hid_acpi.
Following the Fedora user guide at our website, I created a clean installation on the 12th gen.
sudo grubby --update-kernel=ALL --args="module_blacklist=hid_sensor_hub"
Reboot, brightness keys work.
1 Like
Just installed Debian (12) on my 12th gen i5 Main board. I also ran into this issue with the brightness keys not working.
Following the replies on this post, I was able to get the fn keys to work with brightness with the following changes:
- Open a conf file for blacklisting the hid sensor module
sudo -e /etc/modprobe.d/framework.conf
- Paste the following
# Blacklist hid sensor hub to fix fn-key for brightness
blacklist hid-sensor-hub- Save the file with
ctrl+xthenythenEnter - Update initramfs (the important part)
sudo update-initramfs -u
- Reboot
Also, it was somewhat difficult to search around this forum. For example, using the search function for “fn key” didn’t bring up this post. “fn key 12th” did, but the post is located 11 links down the page. 
For anyone blacklisting hid-sensor-hub and finding that it isn’t working: Make sure in your Kernel build options that CONFIG_HID_SENSOR_HUB is not set to y. I believe this overrides the whole modprobe process for that module and forces it to be loaded. Either unset this option or set it to m and then do the modprobe blacklist. Either way be sure to rebuild the kernel and reboot.
FYI, for anyone using Fedora Silverblue or Kinoite, the following worked for me:
rpm-ostree kargs --append=‘hid_sensor_hub.blacklist=1 modprobe.blacklist=hid_sensor_hub’
Hey all,
New framework user there. I’m a bit confused, can anyone explain to me why this happens? From this thread I surmise the following
- the ALS system and the brightness+airplane mode keys are recognized as a single device.
- Since a device can only have one driver, it is picked up by the ALS driver (
hid_sensor_hub) by default, and thus doesn’t handle the key presses - If you want the keys to work, then it has to be handled by another driver, and for that you should blacklist
hid_sensor_hub
I guess my question is the following:
Why are those two (seemingly very different) parts recognized as the same device? shouldn’t the keys just be part of the keyboard (and handled by the keyboard driver)?
3 Likes
Well, I updated to Kubuntu 23.04… and now, not only does the previous workaround for the brightness control keys seem to have stopped working, I’m failing to find any way to control the screen brightness. And whatever level it’s stuck on I’m pretty sure isn’t even the one I had it set to before the update, because I don’t recall that one hurting my eyes to look at. This is kind of a major problem, and I’m very glad the Framework isn’t the only computer I have. I would very much appreciate this being fixed.
@Reese Could you check if your Fn key works?
There is a known bug where Fn would sometimes stopped working, solved with a reboot.
Also, in “any way to control the screen brightness” do you imply that you tried command lines too? That would not depend on the Fn keys.
That’s strange. I did a clean install of Kubuntu 23.04 Beta recently, and the screen brightness worked fine out of the box using the battery widget. Then I added the following lines to /etc/modprobe.d/blacklist-sensor-hub.conf:
blacklist hid_sensor_hub
blacklist hid_sensor_trigger
blacklist hid_sensor_als
Ran sudo update-initramfs -u, rebooted, and the screen brightness control by keys works as well. (The other two lines are probably not even needed.)
Anyway, it’s a shame this issue has been dragging for so long. I wonder if there’s any progress on fixing this properly, i.e. getting auto-brightness sensor to work with the keys at the same time?
Edit: fixed missing blacklist keyword in the modprobe configuration file
2 Likes
Hi @Petr_Sedlacek , been a bit while, welcome back.
thanks for adding info on how brightness control keys could work on kubuntu 23.04.
@Mapleleaf:
I just started my Framework back up after being shut down, and the function key works; I didn’t test it before, but I hadn’t needed it to change screen brightness before the update.
As for changing the screen brightness from the command line, though, I don’t know how to do that.
@Petr_Sedlacek:
Curious. I recall previously having a control for it in the battery widget, but it wasn’t there after the update and still isn’t there now. And this is 23.04, I just checked; I doubt that would have changed from the beta…
I don’t have a blacklist-sensort-hub.conf there, though; I was using a solution involving framework-als-blacklist.conf. I’ll try your solution.
…Hm. It doesn’t look promising, all three lines in the file seem to have been ignored by update-initramfs… but the file I’d been using previously started its line with “blacklist”; I’ll try adding that.
Okay, that didn’t produce error messages. Rebooting…
…Sigh. Nope. No sign of controls in the battery widget, no response from the brightness control keys. I do now have two different files containing “blacklist hid_sensor_hub”; could that somehow be causing a problem?
And yes, I’d very much like it if this just… worked. No fiddling around with blacklist files that sometimes work and sometimes don’t and apparently sometimes stop working for no readily apparent reason.
Oh, thank you both for trying to help, though.
Oops, sorry about that! I was writing the response on my main desktop, so I (incorrectly) typed just the names of the modules without the blacklist keyword. Fixed my comment.
I don’t think the duplicate blacklist hid_sensor_hub line in two different files could be causing any issues - but it’s obviously only needed once. The name of the file it’s in doesn’t matter (I think it just needs to end in .conf to be picked up).
I doubt the module could have loaded for you despite the blacklist configuration, but you can verify by running lsmod | grep sensor in your terminal to see if it lists the hid_sensor_hub. When it did for me the first time (I forgot to run update-initramfs), I just unloaded the module using rmmod hid_sensor_hub and the brightness keys started working immediately.
If the module is not loaded (as it should be), I guess there’s some other issue with brightness controls on your system, as hinted to by the missing brightness slider in the battery widget… I don’t have any more suggestions I’m afraid.
@Petr_Sedlacek:
Ah, thanks for the information.
Hm. I failed to make “lsmod | grep sensor” do anything, as far as I noticed, but that might have been due to my level of skill with Linux.
However, “rmmod hid_sensor_hub” produced an message telling me that “Module hid_sensor_hub is not currently loaded”, so… yeah. I don’t know what’s going on there.
The friend of mine who helped me set up the computer in the first place and is much better with Linux than me might be able to help… but he’s also very busy, and this seems like it might be a complex issue.
Bother.
I did find this online:
It’s not about usage on a Framework, or about the method that was being used here to make brightness controls work, but it is about screen brightness control stopping working on Kubuntu 23.04. Do you think it could be related somehow?
Looking at my own /etc/default/grub, though, I do seem to already have a line “GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash acpi_backlight=vendor acpi_osi=linux””…
I’ve also recently encountered this problem, or a variant of it. I’m using Ubuntu 22.04.1 with kernel 6.0.0-1014-oem on a 12th-gen laptop. I have the hid_sensor_hub module correctly blocklisted, and lsmod confirms it isn’t loaded (and I’m not at all interested in using/having the ALS sensor).
Symptoms
I can manually adjust the brightness using the brightnessctl utility, the problem is only that the backlight keyboard keys aren’t having any effect (including in xev or showkey). (Which means that acpi_backlight and similar settings are irrelevant.)
The following dmesg lines were present on previous boots (with identical kernel version, config, and cmdline), but were missing from the affected boot (on Ubuntu, you can check the kern* files under /var/log for messages from previous boots):
[ 2.223885] input: FRMW0001:00 32AC:0006 Wireless Radio Control as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-2/i2c-FRMW0001:00/0018:32AC:0006.0001/input/input5
[ 2.224061] input: FRMW0001:00 32AC:0006 Consumer Control as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-2/i2c-FRMW0001:00/0018:32AC:0006.0001/input/input6
[ 2.224138] input: FRMW0001:00 32AC:0006 as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-2/i2c-FRMW0001:00/0018:32AC:0006.0001/input/input7
[ 2.224284] hid-generic 0018:32AC:0006.0001: input,hidraw0: I2C HID v1.00 Device [FRMW0001:00 32AC:0006] on i2c-FRMW0001:00
The output from sudo evtest (then ctrl-c when prompted) showed that the following devices, which are normally present, were missing (the “eventXX” number isn’t relevant, only the presence or absence of the line):
/dev/input/event22: FRMW0001:00 32AC:0006 Wireless Radio Control
/dev/input/event23: FRMW0001:00 32AC:0006 Consumer Control
/dev/input/event24: FRMW0001:00 32AC:0006
Further, looking in /sys/bus/i2c/devices/ shows entries for both i2c-FRMW0001:00 and i2c-PIXA3854:00. However, in /sys/bus/i2c/drivers/i2c_hid_acpi/ there is only an entry for i2c-PIXA3854:00. This leads directly to the workaround.
Workaround
Since the i2c-FRMW0001:00 device is known by the kernel, but for whatever reason hasn’t been properly claimed by the i2c_hid_acpi driver, all that’s needed is to get that to happen. Doing this is straight-forward:
echo i2c-FRMW0001:00 | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/bind
This will trigger the missing dmesg lines, the devices will show up in evtest, and the brightness keys will correctly output the right keystrokes.
Since the problem happens at some boot-ups (see the Repro info below), I added a simple systemd service that will perform the workaround if needed. This involved creating a script /usr/local/sbin/framework-i2c-hid-device-fix, and a service file /etc/systemd/system/framework-i2c-hid-device-fix.service to run it. It seems to work alright.
sudo tee /usr/local/sbin/framework-i2c-hid-device-fix <<EOF
#!/bin/bash
# If the framework special keys i2c device is present, but not bound to its driver, then bind it.
ls -lad /sys/bus/i2c/devices/i2c-*:* /sys/bus/i2c/drivers/i2c_hid_acpi/i2c-*:*
if [ -e /sys/bus/i2c/devices/i2c-FRMW0001:00 -a ! -e /sys/bus/i2c/drivers/i2c_hid_acpi/i2c-FRMW0001:00 ]; then
echo fixing
echo i2c-FRMW0001:00 > /sys/bus/i2c/drivers/i2c_hid_acpi/bind
ls -lad /sys/bus/i2c/devices/i2c-*:* /sys/bus/i2c/drivers/i2c_hid_acpi/i2c-*:*
echo done
else
echo no fix needed
fi
EOF
sudo chmod 700 /usr/local/sbin/framework-i2c-hid-device-fix
sudo tee /etc/systemd/system/framework-i2c-hid-device-fix.service <<EOF
[Unit]
After=network.target
[Service]
ExecStart=/usr/local/sbin/framework-i2c-hid-device-fix
[Install]
WantedBy=default.target
EOF
sudo chmod 644 /etc/systemd/system/framework-i2c-hid-device-fix.service
sudo systemctl daemon-reload
sudo systemctl enable framework-i2c-hid-device-fix
sudo systemctl start framework-i2c-hid-device-fix
sudo systemctl status framework-i2c-hid-device-fix
Repro
I was able to reliably reproduce the problem very easily. The problem occurs only on cold boots, ie. after the laptop has been powered off with eg. sudo poweroff, and then the power button pressed. On warm boots, ie. after sudo reboot or similar, the problem does not occur and the brightness keys show up normally.
I have no idea why this happens (though I do wonder if it might be related to the other EC shenanigans I’ve encountered).
However, I think this could possibly explain the strange flapping, where people are seeing it sometimes work, and sometimes not. (Especially since, after blocking the hid_sensor_hub module, people will typically do a warm reboot, and everything will be fine. It’ll only be (potentially much) later that they do a cold boot and have problems.)
11 Likes