[SOLVED-GUIDE] 12th gen not sending XF86MonBrightnessUp / Down

[devkev]

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.)

[Loell_Framework]

thanks @devkev , for a quite a comprehensive guide you’ve added in here.

[Brian_White]

@devkev

echo i2c-FRMW0001:00 | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/bind

doood! great run down! thank you.

[Max_YamlEnthusiast]

FYI Just confirming that the same workaround (blacklisting the hid_sensor_hub module) works on Intel 13th gen.

[Matt_Hartley]

@Max_YamlEnthusiast

FYI Just confirming that the same workaround (blacklisting the hid_sensor_hub module) works on Intel 13th gen.

This is correct and outlined in the guide as well.

[Paul_Bailey]

@kadac00

sudo nano /etc/modprobe.d/framework-als-blacklist.conf
blacklist hid_sensor_hub

and

sudo update-initramfs -u

Confirmed this is needed for the 13th gen. Just got mine and this worked.

[Matt_Hartley]

Yep, this will do it. There are few different approaches, but this works.

[Adam_Spiers]

@Matt_Hartley

When this happens, it will be shouted far and wide. It’s something we’d all like to see.

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:

@Petr_Sedlacek

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.

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!

@Tristan

• the ALS system and the brightness+airplane mode keys are recognized as a single device.
• Since a device can only have one driver, it is picked up by the ALS driver (hid_sensor_hub) by default, and thus doesn’t handle the key presses
• If you want the keys to work, then it has to be handled by another driver, and for that you should blacklist hid_sensor_hub

Why are those two (seemingly very different) parts recognized as the same device? shouldn’t the keys just be part of the keyboard (and handled by the keyboard driver)?

I would love to know this too.

[Matt_Hartley]

@Adam_Spiers

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:

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

[Matt_Hartley]

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

[Matt_Hartley]

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.

[Username009]

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

[Matt_Hartley]

@Username009

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 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 then reboot.

• 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.

---

@devkev

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).

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.

[Matt_Hartley]

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

[Username009]

Hey Matt, the issue does not trigger on reboot. It needs a full power off and a fresh power on.

[Matt_Hartley]

@Username009

Hey Matt, the issue does not trigger on reboot. It needs a full power off and a fresh power on.

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.

[Username009]

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.

[Matt_Hartley]

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.

[Matt_Hartley]

@Username009

Then on the 2nd one, it 100% triggers for me. It’s tedious I’m sorry.

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.

[Username009]

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.