Since it flip flops, the way to 100% reproduce it in my case is:
- power on
- power off completely
- power on
Then on the 2nd one, it 100% triggers for me. It’s tedious I’m sorry.
1 Like
Edited my thoughts above, DHowett has a possible reason why it’s happening and this would also address why it’s not reproducible on our end. It may be unloading on your configuration where it is not having this issue on ours. Which is why we cannot seem to replicate it successfully.
No, you’re fine - my OCD is screaming right now because it’s not a thing on my machine, Loell’s machines or anyone else at work. lol
What does your grub parameters look like? Wondering if something is “pushing off” the blacklisting from boot.
Looking back through devkev’s notes for some additional clues.
May a moot point. Most folks can use the parameters fine (looking at past tickets, etc).
But there may be something triggered where it’s not working for some folks.
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.4.11-200.fc38.x86_64 root=UUID=476d5716-fa96-44a4-82f4-9d92994ff54d ro rootflags=subvol=root rd.luks.uuid=luks-234b5ccd-8326-4baa-951d-f128a8f473f1 rhgb quiet nvme.noacpi=1 module_blacklist=hid_sensor_hub
This is unlikely though, because devkev and I can verify that the module is not loaded, even in situations where the issue triggers.
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.
1 Like
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?
1 Like
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
1 Like
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?
1 Like
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.
1 Like
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?
2 Likes
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.