Confirmed this worked for me on Ubuntu 22.04.1 LTS
sudo nano /etc/modprobe.d/framework-als-blacklist.conf
blacklist hid_sensor_hub
and
sudo update-initramfs -u
3 Likes
I’m seeing this thread being shared around quite a bit when this question pops up elsewhere.
Having the workaround is great, but it’s still unfortunate to have to choose between either having the automatic light sensor or the brightness keys working. Is there any update on having both work at the same time without needing the workaround?
3 Likes
I added module_blacklist=hid_sensor_hub to my grub file… not works
How do I know what is my device ? (EDIT: seems to be event2)
sudo evtest to list all…
Now its works…
I try add :
vim /etc/modprobe.d/framework-als-blacklist.conf
blacklist hid_sensor_hub
(not sure this help)
Thanks
1 Like
Is this something that’s actually being worked on? Anyone running Debian right now is going to encounter this problem and will think that key is broken until they find this forum post and figure out how to use vi. 
1 Like
I asked that almost exactly 2 months ago…radio silence.
3 Likes
Like I finaly said here : Can't set resolution to 1600x1024 (3:2) - #9 by Bonnefille_Vincent
The Brightbuttons woks when the GPU driver is installed
( but this make some apps not working in my case )
I noticed here some use of sudo update-initramfs -u
on Arch (Mnajaro) I use sudo mkinitcpio -P
I suppose it do the same job (carefulle, -P is for “all profiles” : all images)
I finaly follow this :
Are you saying you do not to blacklist the hid_sensor_hub module for the brightness keys to work when the “GPU driver” (which? xf86-intel-driver?) is installed? Because I have what i think is the equivalent of that driver here (xserver-xorg-video-intel, in Debian), and I did need to block the module from loading to get the keys to work (and therefore the light sensor doesn’t work…)
2 Likes
Hello !
I have the same result if I active/blacklist hid_sensor_hub (maybe I dont do it well)
But it works with the driver installed (yes xf86-intel-driver)
( and
Section "Device"
Identifier "Device0"
Driver "intel"
EndSection
not present in /etc/X11/xorg.conf.d/10-monitor.conf )
Sorry, if am not totaly clear, am searching…
V
It is not at all advisable to use the intel Xorg driver, as it lags behind the modesetting driver, which is the basically the same but relying on the version of the GPU driver upstreamed into the official kernel tree, the drm module.
The intel Xorg driver has many shortcomings, and on the other hand there are not at all any performance disadvantages in using the modesetting one.
So, maybe it would seem to temporarily fix the problem by using the intel driver right now, but it would be a much better solution to just blacklist the ambient light sensor module and stick to using the modesetting driver.
And hopefully any time soon a fix will be provided to not have to blacklist the light sensor.
1 Like
Thanks
I try the intel Xorg driver and modesetting .
I noob with Manjaro.
I follow
Change video driver from intel to modesetting - Technical Issues and Assistance - Manjaro Linux Forum
and then, the official wiki
Configure Graphics Cards - Manjaro
But not looking more working apps…
So I go back and try using Intel…
I use sudo mhwd -a pci free 0300 for an auto-install (of video-linux)
and add /etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "DRI" "2" # DRI3 is now default
#Option "AccelMethod" "uxa"
#Option "AccelMethod" "sna" # default
#Option "AccelMethod" "uxa" # fallback
EndSection
because a lot of apps black crashing using DRI 3… but Steam and other games crashing
So, for now, I disable the intel config file…
Sorry, it’s likly an other thread here…
For short : with GPU ON, the brightbutton is working 
I finaly follow Backlight - ArchWiki
allowing <user> changing brightness
sudo usermod -aG video <user>
Then I try to install :
opt1. backlight_control +3
op2. brightnessctl s +10000
(finaly choose opt.2)
wiki Backlight - ArchWiki #Backlight_utilities
Then configure Xfce Keyboard maping :
“Luminosité écran plus forte” key (brigth+ F7) … works*
“Luminosité écran plus faible” key (brigthless F8) … not*
* I finally uninstall GitHub - miXwui/framework-laptop-fn-keys-fix: Fixes for the function keys sticking on the Framework Laptop
(making F8 bad working)
Works !!!
1 Like
@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…
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?
Thanks!
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. lsmod | grep hid_sensor_hub should show nothing.
These instructions should work:
(then reboot)
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.
3 Likes
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