@Bonnefille_Vincent Good that you got it working!
I couldn’t have helped you much, as the solution you found seems to be using a systemd command, and my Linux distrib (Artix) is without systemd.
Anyway, I plan to switch soon to the new 12th gen model (currently on the 11th), and I’ll see how it all works out…
@Bonnefille_Vincent Good that you got it working!
Here’s what worked for me for Arch Linux on the 12th Gen Framework Laptop (Intel i5).
# Blacklist the hid_sensor_hub kernel module sudo vi /etc/modprobe.d/framework-enable-brightness-keys.conf # Add the following line in the file, in vi blacklist hid_sensor_hub # Save and exit vi
Reboot your computer.
The brightness keys started working.
This is also documented in the ArchWiki → Framework Laptop
I’ve not been able to make fixes from this thread work so far, and I’m currently hoping that, as was suggested might happen, an official fix will be developed and released. I’m relatively new to both the Framework and Linux (Kubuntu), though; if there is a fix released, will it be pushed out as an update that’ll just show up on my computer like other updates, or will I need to do more manually than just approve it? If the latter, how would I know when the fix is available?
It works on my Kubuntu 22.04 12th gen Framework with
hid_sensor_hub blacklisted. I would make sure that
hid_sensor_hub was actually blacklisted by making sure that it isn’t in the ouptut from
lsmod | grep hid_sensor_hub should show nothing.
These instructions should work:
All these “solutions” are really workarounds. Disabling a useful feature (the auto-brightness sensor) is not what I’d call a solution
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.
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.
I would very much hope we would be notified here in this thread.
When this happens, it will be shouted far and wide. It’s something we’d all like to see.
That worked; thanks!
“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.”
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.
sudo echo “blacklist hid_sensor_hub” > /etc/modprobe.d/framework-als-blacklist.conf
sudo update-initramfs -u
Fixed it for me, it also fixed the media keys
this is flapping for me.
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
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.
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
- Update initramfs (the important part)
sudo update-initramfs -u
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’
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
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)?
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
blacklist hid_sensor_hub blacklist hid_sensor_trigger blacklist hid_sensor_als
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