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

Framework Laptop 13 Linux
67

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