Yeah, that looks fine to me.
That is so odd. Okay, well this is going to have to have a pin put into it. Grub for most, devkev’s approach for anyone experiencing this.
Going to pin this and mark as a potential workaround guide in case anyone else is seeing this. Man, I just want repro this one time. Would help me to have something to dig into. But this is solid workaround in case it crops up again in later BIOS releases.
Thanks everyone for letting me sort through this. It was rough, but I’ve determined:
- Can’t seem to duplicate it here in my office and Loell also has not been able to duplicate this.
- Others here have shown it’s a thing they’ve experienced and there is another workaround devkev came up with that is resolving this for those affected.
Should the standard GRUB_CMDLINE_LINUX_DEFAULT="quiet splash module_blacklist=hid_sensor_hub"
fail for anyone, please use kevdev’s method linked below.
In multiple tests, we were not able to reproduce cold boot, warm boot, Fedora and Ubuntu. But if find that you’re not able to get the brightness keys working, the method below has been confirmed to help.
Big props to @devkev for the solution that is working for them and will help others if it fails to operate correctly.
You can also enable it temporally by running sudo rmmod hid_sensor_trigger hid_sensor_iio_common hid_sensor_als hid-sensor-hub
to unload the module and dependends.
Do any of the solutions here apply for the 11th gen?
I just updated bios (Fedora 38) from 3.03 to 3.17 and the function keys to control screen brightness are not doing anything, but they were working before the update. I also could not find anything in settings for screen brightness. All other function keys are working.
Did not see the file /etc/modprobe.d/framework-als-blacklist.conf.
If your have a standard, untouched grub configuration on 11th Gen, it’s not needed. You have no other odd blacklisting or tweaks made? Does this also happen on a live usb of 38?
No blacklisting. Some minor tweaks that I always do when reinstalling OS. Fn keys were workinf with live usb.
I got it working again after a reinstall of OS. Thanks for the help
Okay, awesome to hear. Appreciate the update on the good news.
Sorry to revive this thread, but i did recently a fresh install of Fedora 39 on my Intel 12th Gen and before i added the “module_blacklist=hid_sensor_hub” line as kernel args (as mentioned in the official guide), i noticed the brightness keys are working! The automated brightness is also working (covering the top of the screen lets the screen get dimmer, releasing the top makes it brighter).
So on my device screen brightness via keyboard and the automatic one worked out of the box!
@Matt_Hartley so maybe this step isnt necessary anymore?
On Arch, I noticed that the brightness keys were actually working around kernel 6.6.6 - I never bothered to blacklist the ambient light sensor because I usually just use the slider to change brightness.
Interesting, my 12th gen board is not in front of me atm, @Loell_Framework can you test Fedora 39 latest kernel on a 12th gen board and see if we can get brightness keys working without module_blacklist=hid_sensor_hub anymore?
Hi, brand new Framework customer here! Very excited about my AMD Framework 13 I set up with Fedora 39 (I may switch to Ubuntu 24.04 in the future when released and supported, I’ll decide on that later).
I understand this is a 12th gen Intel problem thread, but I appear to have the same issue with my AMD version; On initial set up the brightness keys did work, but sometime between then and when I tried again (all updates installed and other quick-start guide steps followed, and almost nothing else), they stopped working. I did note after I looked it up and found this thread, that automatic brightness does work, but if I had to choose I would pick the buttons.
So my question is: Despite the guide targeting 12th-gen Intel, would folks recommend trying the same procedure? Should I create an entirely new thread for it on account of not being 12th gen?
It’s a Linux driver issue, so it’s entirely possible the situation is the same for the AMD version.
The easiest way to find out is to simply try the solution - it will take you 2 minutes to add the module_blacklist
kernel argument and reboot. Then you will know.
Thanks for the response. Just to follow up, prior to attempting this, I had to take steps on a more pressing AMD-related display problem (this one), and on restart my brightness buttons worked again. I had disabled auto-brightness via the UI, so it’s possible that combined with the restart might do away with the issue for me, but I might be speaking too soon. I’ll keep this in my back pocket for now but I cannot confirm at this time whether it’s the same problem.
Whoa. It works.
UPDATE: see below, it doesn’t actually work.
Without the module block.
I am running Debian bookworm with the stable backport, which means the 6.6.13 kernel:
Linux angela 6.6.13+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.13-1~bpo12+1 (2024-02-15) x86_64 GNU/Linux
The hid_sensor_als
is loaded:
anarcat@angela:~$ lsmod | grep ^hid_sensor
hid_sensor_als 16384 0
hid_sensor_trigger 20480 2 hid_sensor_als
hid_sensor_iio_common 20480 2 hid_sensor_trigger,hid_sensor_als
hid_sensor_hub 28672 3 hid_sensor_trigger,hid_sensor_iio_common,hid_sensor_als
and the buttons just work. I love when that happens.
I have no idea if the sensor stuff works, mind you, so I don’t actually know if the light detection part works now. That’s less an issue for me, but I actually would love to hook into that to configure brightness on my other monitors…
Would be interesting to get to the bottom of this and see which commit fixed the Linux kernel regarding this issue.
Well, that’s a downer: it does not actually work. I must of forgotten something along the way (i did reboot, I swear) because right now nothing works, not even the fn lock stuff, it’s kind of infuriating.
Had @Loell_Framework test the 12th gen, generic install of Fedora, no module_blacklist=hid_sensor at all - brightness keys (the labeled brightness keys) worked out of the box upon installation.