3

On Ubuntu 22.10 (hence kernel 5.19, gnome 43.1)

HP Spectre x360 2-in-1 16-f1xxx, i7-12700H, Iris XE (ADL GT2)

When switching between laptop and tablet mode, the airplane mode automatically toggles.

Expected behaviour: No link between tablet mode and airplane mode.

This can be seen as an update on the old Why does "Airplane Mode" keep toggling on my HP laptop in Ubuntu 18.04?

The systemd solution described within was tried, and did not work. Notice that somebody commented that this fix does not work anymore (for him) on 22.04 .

I explored a little, and noticed that when using sudo showkey -s, no event registers. However, with sudo showkey -k, we get

keycode 247 press keycode 247 release

So showkey does not get the scancode, but only the keycode.

Apparently keycode 247 is KEY_RFKILL, which is indeed airplane mode.

Further, the culprit seems to be "Intel HID events". With evtest I get:

$ sudo evtest /dev/input/event17
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: "Intel HID events"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 69 (KEY_NUMLOCK)
    Event code 102 (KEY_HOME)
    Event code 104 (KEY_PAGEUP)
    Event code 107 (KEY_END)
    Event code 109 (KEY_PAGEDOWN)
    Event code 113 (KEY_MUTE)
    Event code 114 (KEY_VOLUMEDOWN)
    Event code 115 (KEY_VOLUMEUP)
    Event code 116 (KEY_POWER)
    Event code 142 (KEY_SLEEP)
    Event code 164 (KEY_PLAYPAUSE)
    Event code 166 (KEY_STOPCD)
    Event code 224 (KEY_BRIGHTNESSDOWN)
    Event code 225 (KEY_BRIGHTNESSUP)
    Event code 240 (KEY_UNKNOWN)
    Event code 247 (KEY_RFKILL)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Properties:
Testing ... (interrupt to exit)
Event: time 1671615870.717544, type 4 (EV_MSC), code 4 (MSC_SCAN), value 08
Event: time 1671615870.717544, type 1 (EV_KEY), code 247 (KEY_RFKILL), value 1
Event: time 1671615870.717544, -------------- SYN_REPORT ------------
Event: time 1671615870.717556, type 1 (EV_KEY), code 247 (KEY_RFKILL), value 0
Event: time 1671615870.717556, -------------- SYN_REPORT ------------
Event: time 1671615871.877965, type 4 (EV_MSC), code 4 (MSC_SCAN), value 08
Event: time 1671615871.877965, type 1 (EV_KEY), code 247 (KEY_RFKILL), value 1
Event: time 1671615871.877965, -------------- SYN_REPORT ------------
Event: time 1671615871.877980, type 1 (EV_KEY), code 247 (KEY_RFKILL), value 0
Event: time 1671615871.877980, -------------- SYN_REPORT ------------
Event: time 1671615876.441854, type 4 (EV_MSC), code 4 (MSC_SCAN), value 08
Event: time 1671615876.441854, type 1 (EV_KEY), code 247 (KEY_RFKILL), value 1
Event: time 1671615876.441854, -------------- SYN_REPORT ------------
Event: time 1671615876.441866, type 1 (EV_KEY), code 247 (KEY_RFKILL), value 0
Event: time 1671615876.441866, -------------- SYN_REPORT ------------

Does that mean the ``bad'' scancode is 08? How can I ensure it does not trigger again?

3 Answers3

2

OK, with further work, I could set up a solution, inspired by https://wiki.archlinux.org/title/Map_scancodes_to_keycodes

I created a file /etc/udev/hwdb.d/91-solve-airplane.hwdb

# Spectre x360 16 2022 (Prevents Random airplane mode)
evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pn*HP[sS][pP][eE][cC][tT][rR][eE]*x3602-in-1*:*
 KEYBOARD_KEY_08=unknown

The end of the long line starting with evdev:name:Intel HID events must match /sys/class/dmi/id/modalias . The start was the device responsible. The keyboard key number 08 is the bad scancode.

After that

 sudo systemd-hwdb update
 sudo udevadm trigger

should work for the session. To have it permanent, use

sudo systemctl edit --full systemd-hwdb-update.service

and comment out the line

ConditionNeedsUpdate=/etc

Save to /etc/systemd/system/systemd-hwdb-update.service

You should be done.

0

UPDATE: This solution is obsolete, I found a better solution that addresses the root of the issue. There is a bug in Intel's HID driver, to fix, follow the instructions at https://askubuntu.com/a/1483259/1688756

I found a solution that works on any desktop with any distro, and doesn't require you to make a kernel module or anything complicated like that.

https://askubuntu.com/a/1463613/1688756

In short, you download and set up a program called Hawck, rebind keycode 255 (the rfkill key, which is what triggers when the lid switch activated) to a null character, set Hawck to run on boot, and the problem is solved. Cheers!

  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Community Apr 14 '23 at 14:27
0

I had the same issue and managed to fix it using your method. However, I needed a different device specification in the .hwdb file. To find out which one exactly, I refer to https://yulistic.gitlab.io/2017/12/linux-keymapping-with-udev-hwdb/.

Furthermore, I did not have to make the changes permanent. After reboot, the issue is still fixed. Time will tell if updates unfix anything.

See https://askubuntu.com/a/1468311/1696813 for my answer and more details.

Cheers jk

jk_
  • 36