Hi @Petr_Sedlacek , been a bit while, welcome back.
thanks for adding info on how brightness control keys could work on kubuntu 23.04.
@Mapleleaf:
I just started my Framework back up after being shut down, and the function key works; I didn’t test it before, but I hadn’t needed it to change screen brightness before the update.
As for changing the screen brightness from the command line, though, I don’t know how to do that.
@Petr_Sedlacek:
Curious. I recall previously having a control for it in the battery widget, but it wasn’t there after the update and still isn’t there now. And this is 23.04, I just checked; I doubt that would have changed from the beta…
I don’t have a blacklist-sensort-hub.conf there, though; I was using a solution involving framework-als-blacklist.conf. I’ll try your solution.
…Hm. It doesn’t look promising, all three lines in the file seem to have been ignored by update-initramfs… but the file I’d been using previously started its line with “blacklist”; I’ll try adding that.
Okay, that didn’t produce error messages. Rebooting…
…Sigh. Nope. No sign of controls in the battery widget, no response from the brightness control keys. I do now have two different files containing “blacklist hid_sensor_hub”; could that somehow be causing a problem?
And yes, I’d very much like it if this just… worked. No fiddling around with blacklist files that sometimes work and sometimes don’t and apparently sometimes stop working for no readily apparent reason.
Oh, thank you both for trying to help, though.
Oops, sorry about that! I was writing the response on my main desktop, so I (incorrectly) typed just the names of the modules without the blacklist keyword. Fixed my comment.
I don’t think the duplicate blacklist hid_sensor_hub line in two different files could be causing any issues - but it’s obviously only needed once. The name of the file it’s in doesn’t matter (I think it just needs to end in .conf to be picked up).
I doubt the module could have loaded for you despite the blacklist configuration, but you can verify by running lsmod | grep sensor in your terminal to see if it lists the hid_sensor_hub. When it did for me the first time (I forgot to run update-initramfs), I just unloaded the module using rmmod hid_sensor_hub and the brightness keys started working immediately.
If the module is not loaded (as it should be), I guess there’s some other issue with brightness controls on your system, as hinted to by the missing brightness slider in the battery widget… I don’t have any more suggestions I’m afraid.
@Petr_Sedlacek:
Ah, thanks for the information.
Hm. I failed to make “lsmod | grep sensor” do anything, as far as I noticed, but that might have been due to my level of skill with Linux.
However, “rmmod hid_sensor_hub” produced an message telling me that “Module hid_sensor_hub is not currently loaded”, so… yeah. I don’t know what’s going on there.
The friend of mine who helped me set up the computer in the first place and is much better with Linux than me might be able to help… but he’s also very busy, and this seems like it might be a complex issue.
Bother.
I did find this online:
It’s not about usage on a Framework, or about the method that was being used here to make brightness controls work, but it is about screen brightness control stopping working on Kubuntu 23.04. Do you think it could be related somehow?
Looking at my own /etc/default/grub, though, I do seem to already have a line “GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash acpi_backlight=vendor acpi_osi=linux””…
I’ve also recently encountered this problem, or a variant of it. I’m using Ubuntu 22.04.1 with kernel 6.0.0-1014-oem on a 12th-gen laptop. I have the hid_sensor_hub module correctly blocklisted, and lsmod confirms it isn’t loaded (and I’m not at all interested in using/having the ALS sensor).
Symptoms
I can manually adjust the brightness using the brightnessctl utility, the problem is only that the backlight keyboard keys aren’t having any effect (including in xev or showkey). (Which means that acpi_backlight and similar settings are irrelevant.)
The following dmesg lines were present on previous boots (with identical kernel version, config, and cmdline), but were missing from the affected boot (on Ubuntu, you can check the kern* files under /var/log for messages from previous boots):
[ 2.223885] input: FRMW0001:00 32AC:0006 Wireless Radio Control as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-2/i2c-FRMW0001:00/0018:32AC:0006.0001/input/input5
[ 2.224061] input: FRMW0001:00 32AC:0006 Consumer Control as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-2/i2c-FRMW0001:00/0018:32AC:0006.0001/input/input6
[ 2.224138] input: FRMW0001:00 32AC:0006 as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-2/i2c-FRMW0001:00/0018:32AC:0006.0001/input/input7
[ 2.224284] hid-generic 0018:32AC:0006.0001: input,hidraw0: I2C HID v1.00 Device [FRMW0001:00 32AC:0006] on i2c-FRMW0001:00
The output from sudo evtest (then ctrl-c when prompted) showed that the following devices, which are normally present, were missing (the “eventXX” number isn’t relevant, only the presence or absence of the line):
/dev/input/event22: FRMW0001:00 32AC:0006 Wireless Radio Control
/dev/input/event23: FRMW0001:00 32AC:0006 Consumer Control
/dev/input/event24: FRMW0001:00 32AC:0006
Further, looking in /sys/bus/i2c/devices/ shows entries for both i2c-FRMW0001:00 and i2c-PIXA3854:00. However, in /sys/bus/i2c/drivers/i2c_hid_acpi/ there is only an entry for i2c-PIXA3854:00. This leads directly to the workaround.
Workaround
Since the i2c-FRMW0001:00 device is known by the kernel, but for whatever reason hasn’t been properly claimed by the i2c_hid_acpi driver, all that’s needed is to get that to happen. Doing this is straight-forward:
echo i2c-FRMW0001:00 | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/bind
This will trigger the missing dmesg lines, the devices will show up in evtest, and the brightness keys will correctly output the right keystrokes.
Since the problem happens at some boot-ups (see the Repro info below), I added a simple systemd service that will perform the workaround if needed. This involved creating a script /usr/local/sbin/framework-i2c-hid-device-fix, and a service file /etc/systemd/system/framework-i2c-hid-device-fix.service to run it. It seems to work alright.
sudo tee /usr/local/sbin/framework-i2c-hid-device-fix <<EOF
#!/bin/bash
# If the framework special keys i2c device is present, but not bound to its driver, then bind it.
ls -lad /sys/bus/i2c/devices/i2c-*:* /sys/bus/i2c/drivers/i2c_hid_acpi/i2c-*:*
if [ -e /sys/bus/i2c/devices/i2c-FRMW0001:00 -a ! -e /sys/bus/i2c/drivers/i2c_hid_acpi/i2c-FRMW0001:00 ]; then
echo fixing
echo i2c-FRMW0001:00 > /sys/bus/i2c/drivers/i2c_hid_acpi/bind
ls -lad /sys/bus/i2c/devices/i2c-*:* /sys/bus/i2c/drivers/i2c_hid_acpi/i2c-*:*
echo done
else
echo no fix needed
fi
EOF
sudo chmod 700 /usr/local/sbin/framework-i2c-hid-device-fix
sudo tee /etc/systemd/system/framework-i2c-hid-device-fix.service <<EOF
[Unit]
After=network.target
[Service]
ExecStart=/usr/local/sbin/framework-i2c-hid-device-fix
[Install]
WantedBy=default.target
EOF
sudo chmod 644 /etc/systemd/system/framework-i2c-hid-device-fix.service
sudo systemctl daemon-reload
sudo systemctl enable framework-i2c-hid-device-fix
sudo systemctl start framework-i2c-hid-device-fix
sudo systemctl status framework-i2c-hid-device-fix
Repro
I was able to reliably reproduce the problem very easily. The problem occurs only on cold boots, ie. after the laptop has been powered off with eg. sudo poweroff, and then the power button pressed. On warm boots, ie. after sudo reboot or similar, the problem does not occur and the brightness keys show up normally.
I have no idea why this happens (though I do wonder if it might be related to the other EC shenanigans I’ve encountered).
However, I think this could possibly explain the strange flapping, where people are seeing it sometimes work, and sometimes not. (Especially since, after blocking the hid_sensor_hub module, people will typically do a warm reboot, and everything will be fine. It’ll only be (potentially much) later that they do a cold boot and have problems.)
11 Likes
doood! great run down! thank you.
FYI Just confirming that the same workaround (blacklisting the hid_sensor_hub module) works on Intel 13th gen.
1 Like
This is correct and outlined in the guide as well.
1 Like
Confirmed this is needed for the 13th gen. Just got mine and this worked.
1 Like
Yep, this will do it. There are few different approaches, but this works.
It would be really helpful to hear whether Framework (or anyone) is working on or planning to work on proper kernel support to fix this properly, bearing in mind that the current situation is a very poor workaround:
Imagine the uproar if Apple told their users “you can either have a working ambient light sensor or working brightness keys, but not both”!
Even hearing Framework say “sorry, we’re too busy with other things right now” or “sorry but we’re unlikely to ever do this because we can’t justify the engineering cost vs. business benefit” would be far preferable to the uncertainty of the current situation. Either of these responses might even provide the incentive for some kind kernel hacker to do it themselves!
I would love to know this too.
1 Like
Appreciate the feedback. For 12th and 13th gen, this is what we have that works. Now, this may change in the future. At this time for this generation of Intel, this is the workaround we have available.
What we have presented is an actionable workaround for Intel 12th and 13th gen boards.
Since this on course to devolve into something non-constructive, I would ask that we wrap this up here. Thank you
Due to new details in a ticket, I will be replicating this tomorrow with the following, to see if something new has taken place.
Ubuntu 22.4.3 which installing the OEM C kernel via the guide should have users on 6.1.0-1019-oem.
Fedora 38 with the latest updates and kernels.
If something has changed, and the needed tweaks are required after confirming duplication.
Thank you
1 Like
Closing the loop on this. @Loell_Framework and myself have confirmed this is absolutely working on 12th gen and we have not been able to replicate the cold boot experience where it does not. Personally did 3 separate clean installs and updated it to test this.
sudo grubby --update-kernel=ALL --args="module_blacklist=hid_sensor_hub"
Reboot
This is on a single OS installed nvme drive, Fedora 38.
This leads me to believe something else is at play for those affected by this on Fedora 38, latest updates installed.
- Are there other distros on your hard drive? If so, this would be why it’s not working. I’ve found this is where most people run into issues.
- Are you also booting Windows?
- Any other specific configurations not out of the box?
- We will attempt to try different configurations with cold boots, but it’s been working over and over for us.
Not taking away from anyone’s experiences - I understand this happened to some folks. But we need to be able to replicate this and folks, even internally, this method remains working.
For the record, I have exactly the same issue as devkev reports. His solution of binding to i2c_hid_api is the only solution, only blacklisting the ALS by blacklisting hid_sensor_hub is not enough.
I’ve provided support with video proof, I’ve reinstalled many times upon support request, swapped out SSDs, memory, flash drives and distro’s (not only on Fedora, also Ubuntu) and have been consistently been reproducing the issue. Only this command works:
echo i2c-FRMW0001:00 | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/bind
I understand that on your system and theirs. However, something must be different - which is what we’re trying to determine. 
This is a matter of us being completely unable to duplicate this failure.
We have not, at all, but able to get the boot parameter not to work.
For some reason, something, somewhere is different - we need to identify what that is.
We also use this internally for our software devs (they use this parameter on Ubuntu for their laptops).
Now, for you all, you have a workaround that is working and that’s solid.
However, it is critical that folks who happen upon this thread do not believe that this is a hard requirement - it is not unless we can spot what you two have different than what we have on our own systems, and those systems used by our own software team.
We vet and retest to keep our workflows current and as of yesterday, we have found that the grub parameter stands on the 12th gen mainboards tested.
Now, obviously this is an issue…but it’s maddening that we don’t see it here. At all, whatsoever. 
I’d love to get to the bottom of this.
Those affected, can you let me know
-
what is connected to your Framework when you tried
sudo grubby --update-kernel=ALL --args="module_blacklist=hid_sensor_hub"and thenreboot. -
Which BIOS release you’re using?
-
Which distribution and kernel you’re using?
-
Confirm this affecting your 12th gen board?
-
While connected to AC power (if so, which charger?)
Some of this will sound absurd, however, we cannot seem to replicate this issue on our end whatsoever - it just works for us - Fedora 38 and Ubuntu 22.04.3.
Appreciate this folks. I will test again, one more time today myself. My tests are detached from everything except AC power.
My next test will be with current release of 22.04.3 - although this also worked when tested on 22.04.2 as well. This will be with current linux-oem-22.04c which is currently 6.1.0.1019.19
Stay tuned, updating shortly.
1 Like
Re-test one:
Framework 13, 12th gen i5-1240
BIOS 3.04
Ubuntu 22.04.3
Kernel 6.1.0-1019-oem
No external anything attached, just AC power to USB-C.
Only these parameters used: quiet splash module_blacklist=hid_sensor_hub
/etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash module_blacklist=hid_sensor_hub"
sudo update-grub
Reboot
Brightness keys worked in this test.
Will repeat the process on Fedora 38, using grubby later this afternoon.
Next re-test will be on 3.06 BIOS, 12th gen i7-1280p
1 Like
Hey Matt, the issue does not trigger on reboot. It needs a full power off and a fresh power on.
1 Like
Appreciate this, my 3.04 BIOS machine is off (Ubuntu). Going to power on and test.
Powering on cold with Ubuntu. Tested, keys worked. Hmmm This is tough. Tested on battery and attached to power.
Spoke to @DHowett and they brought up an interesting point. What if for some reason, it’s not propagated to the ramdisk. This would be why none of us could duplicate it.
I’m setting up the 3.06 machine now.
1 Like