@Kieran_Levin I guess you meant (note the _
instead of -
):
blacklist hid_sensor_hub
Update: on Ubuntu 22.04, I also had to run update-initramfs -u
before the reboot for the changes to take effect.
@Kieran_Levin I guess you meant (note the _
instead of -
):
blacklist hid_sensor_hub
Update: on Ubuntu 22.04, I also had to run update-initramfs -u
before the reboot for the changes to take effect.
Unfortunately blacklisting the kernel module didn’t do the trick. It did get blacklisted, as evident by the output of lsmod
, but the brightness keys aren’t detected by KDE Plasma and xinput
on Arch Linux.
I guess you meant (note the _ instead of -): blacklist hid_sensor_hub Unfortunately blacklisting the kernel module didn’t do the trick. It did get blacklisted, as evident by the output of lsmod, but the brightness keys aren’t detected by KDE Plasma and xinput on Arch Linux.
@ConfuSomu It’s working here on my Arch, did you forget to run mkinitcpio -p linux
?
Hi all,
Just to confirm black-listing the hid_sensor_hub
as described above along with running the update-initramfs -u
before the reboot fixed both screen brightness buttons and the airplane mode button on Ubuntu 22.04 LTS.
Thanks everyone for the thread.No further issues on my 12gen Intel MOBO upgrade.everything seems to be working as far as I can tell since yesterday.
Baskin
@ConfuSomu It’s working here on my Arch, did you forget to run
mkinitcpio -p linux
?
I’m on Arch Linux as well and tried both
blacklist hid-sensor-hub
and
blacklist hid_sensor_hub
each followed by sudo mkinitcpio -p linux
, shutting down the laptop and booting it up again. Unfortunately neither worked (I checked with sudo evtest /dev/input/event2
and verified that nothing happens when press the brightness up/down keys.)
I get a few warnings during sudo mkinitcpio -p linux
about ‘Possibly missing firmware …’; could that have anything to do with the problem?
I checked with
sudo evtest /dev/input/event2
If your input devices are anything like mine where 2 is the keyboard then you’re testing the wrong device. The brightness buttons are on a different input device. On my machine it’s /dev/input/event4
I think I had to fix the permissions as well of the backlight device.
I’ve added my user to the video group and created the following udev rule to make it permanent:
SUBSYSTEM=="backlight", ACTION=="add", \
RUN+="/bin/chgrp video /sys/class/backlight/%k/brightness", \
RUN+="/bin/chmod g+w /sys/class/backlight/%k/brightness",
I get a few warnings during
sudo mkinitcpio -p linux
about ‘Possibly missing firmware …’;
Probably not but depends what exactly is missing. On newer kernels it usually shows up for amdgpu but that doesn’t matter.
Hi there,
As anyone sent a ticket to Framework for it to be corrected ?
For me it is anoying because in the morning I want to set it below 3% and I am afraid to set it to 0 and then to get a dark screen. Without a hardware key to set it back !
What’s the point of a ticket to Framework? Since @Kieran_Levin posted about it, Framework definitely knows about the problem and gave a simple to implement workaround.
If you want it to work OOTB you’re best off submitting a ticket to your distro since if you want a fix that works automatically you’d not only need to release an upstream kernel patch, but also would need to make sure your distro adopts it and rolls it out in an auto-update.
I’d suggest you just use the workaround as the easiest and fastest way to fix things, but in case you do get your backlight stuck at 0% you could also learn the shortcut to open a terminal and make sure you have a command line app like light
to change the backlight (this of course can be done through SSH or sending a value to the proper sysfs device path as well. I’d suggest SSH is a better option than typing blind). I’ve also noticed that if the backlight is set to 0% and I suspend the laptop it tends to come back at 100%, but maybe that’s a peculiarity of how Arch does suspend/resume.
ADIT 13rd sept : updated the ubuntu 22 default kernel via update center… today and now nowit works on 5.15 ! (?)
EDIT: booting on kernel 5.15 instead of 5.18 reset the behaviour. Trying to do sudo update-initramfs -u again and reboot but it didn t work with htis kernel
So it worked for me on Ubunru Mate 22.04 using kernel 5.18
sudo nano /etc/modprobe.d/framework-als-blacklist.conf
=> it creates an empty file.
Then add:
blacklist hid_sensor_hub
Then do :
sudo update-initramfs -u
What a joy to have a fully functionnal Framework laptop ! I tend to use brightness every 30 minutes especially in the morning.
blacklist hid_sensor_hub
OK, that worked form me as well (after the usual update-initramfs -u
). I already had module_blacklist=hid_sensor_hub
kernel parameter set, but that didn’t help despite the fact that the module was not actually loaded. Not sure why
Is there a way to set the lowest brightnes lower ?
I mean to change the behaviour of the + / - brightness to increment in 1%.
Currentely on my Ubuntu mate when using the buttons it increments by 5% which is fine on the highest values, but in the morning I like to reach 1% 2% 3% gradually as the sun goes up . For now my work arround is to go in battery settings and move slider to 2%.
On my previous E590 the max brightness was less so the scale would benefit more to lower values, therefore this was not anoying in the morning.
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
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?
If your input devices are anything like mine where 2 is the keyboard then you’re testing the wrong device. The brightness buttons are on a different input device. On my machine it’s
/dev/input/event4
If your input devices are anything like mine where 2 is the keyboard then you’re testing the wrong device. The brightness buttons are on a different input device. On my machine it’s /dev/input/event4 I think I had to fix the permissions as well of the backlight device. I’ve added my user to the video group and created the following udev rule to make it permanent: SUBSYSTEM=="backlight", ACTION=="add", \ RUN+="/bin/chgrp video /sys/class/backlight/%k/brightness", \ RUN+="/bin/chmod g+w /s…
module_blacklist=hid_sensor_hub
to my grub file… not workssudo 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)
Fixes for the function keys sticking on the Framework Laptop - miXwui/framework-laptop-fn-keys-fix
Thanks
I have a thread with some of the linux hid subsystem maintainers, and the conclusion is the way the Linux Kernel is currently written, we should just write a framework driver to support both.
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
.
Is this something that’s actually being worked on?
I asked that almost exactly 2 months ago…radio silence.
So are we saying there’s an action item here: Framework to update Linux guides for 12th gen boards? Already there. Are we also saying there’s an action item here too: Framework to develop driver to support both modes? I guess I’m asking: What’s the path forward, and what does it mean?
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 :
#### Blacklisting a kernel module
- Some modules are loaded as part of the initramfs. `mkinitcpio -M` will print out all automatically detected modules:
to prevent the initramfs from loading some of those modules, blacklist them in `/etc/modprobe.d/modprobe.conf`
- Running `mkinitcpio -v` will list all modules pulled in by the various hooks:
```
mkinitcpio -v
```
This file has been truncated. show original
The Brightbuttons woks when the GPU driver is installed
( but this make some apps not working in my case )
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…)
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