[SOLVED] Phantom keypresses occurring every 10 seconds or so

KorvinSilver · 2025-04-20 14:10:05

I noticed a bit ago that in certain programs or games there are inputs I didn't initiate, something pops up that shouldn't, a window closes when it shouldn't as if I clicked outside it, during video playback the controls show while they shouldn't, my typing gets interrupted for a moment, etc. I found with xev that there is a keypress every 10 second or so, always the same.

KeyPress event, serial 39, synthetic NO, window 0x2e00001,
    root 0x405, subw 0x0, time 544480845, (1125,-871), root:(1506,29),
    state 0x10, keycode 248 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 39, synthetic NO, window 0x2e00001,
    root 0x405, subw 0x0, time 544480845, (1125,-871), root:(1506,29),
    state 0x10, keycode 248 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

I can disconnect every USB device but it doesn't stop. I also noticed a message in my journal that seemingly coincides with this, every 10 second or so

kernel: asus_wmi: Unknown key code 0xe5

After a reboot it goes away but eventually it starts showing up again. Tried searching for this issue but seemingly everything about keypresses that shouldn't happen or this specific asus_wmi message lead to dead ends, for example in one post here a year ago it was an issue with plugging in the charger, but that was a different key code, there's only a single post on the Manjaro forum with this message but that was an issue with the keyboard not working after a while.

I have this problem under KDE, with both X and Wayland. Since I first noticed it there were multiple updates to Linux, other drivers, Plasma itself.

OS: Arch Linux x86_64
Host: ASUS TUF Gaming F15 FX506HE_FX506HE 1.0
Kernel: 6.14.2-arch1-1
DE: Plasma 6.3.4

Here's the journal from the past 24 hours, my uptime is over 6 days but the issue only started yesterday evening.
https://gitlab.com/-/snippets/4836233/r … tfile1.txt

Last edited by KorvinSilver (2025-04-26 14:10:57)

seth · 2025-04-20 17:04:20

issue with plugging in the charger, but that was a different key code

I'd not hang up on the specific code - is this linked to charging the device?

KorvinSilver · 2025-04-20 17:16:40

seth wrote:

issue with plugging in the charger, but that was a different key code
I'd not hang up on the specific code - is this linked to charging the device?

No, the keypresses starting doesn't coincide with putting it on charger and they don't stop if I take it off (though off charger this laptop throttles so hard it's borderline useless so it's always on)

Last edited by KorvinSilver (2025-04-20 17:17:58)

seth · 2025-04-21 06:30:52

I'm not sure how the void key would cause the symptoms you describe (you can eg. use it to prevent screensavers/dpms and the 10s frequency almost sounds as if it's a heartbeat) but you'll likely be able to disable the Asus WMI input device with xinput to hide it from X11.

Also

Apr 20 07:56:28 atsuko input-remapper-service[939]: Found "ELECOM TrackBall Mouse HUGE TrackBall", "Logitech G305", "TESORO TESORO keyboard", "input-remapper ELECOM TrackBall Mouse HUGE TrackBall forwarded", "input-remapper keyboard", "ELAN1203:00 04F3:307A Mouse", "Asus WMI hotkeys", "Intel HID events", "Asus Wireless Radio Control", "AT Translated Set 2 keyboard", "Microsoft_KM-V1.3", "Logitech K400 Plus", "Video Bus", "Sleep Button"
Apr 20 07:56:31 atsuko input-remapper-service[939]: Found "SteelSeries Arctis Nova Pro Wireless", "input-remapper ELECOM TrackBall Mouse HUGE TrackBall forwarded", "ELECOM TrackBall Mouse HUGE TrackBall", "Logitech G305", "TESORO TESORO keyboard", "input-remapper keyboard", "ELAN1203:00 04F3:307A Mouse", "Asus WMI hotkeys", "Intel HID events", "Asus Wireless Radio Control", "AT Translated Set 2 keyboard", "Microsoft_KM-V1.3", "Logitech K400 Plus", "Video Bus", "Sleep Button"

Makes me wonder whether this is actually coming from your HPs…

KorvinSilver · 2025-04-22 08:03:26

Okay, so, it seems it stopped on its own soon after I last checked on it after I replugged the charger, at least the asus_wmi messages but I can't see the keys with xev, either. Was it really the charger? I'll check it again when it comes back to make sure, could take a few days, though, but I'll try and see exactly how long it takes after I unplug and plug the charger back in, and mark the exact time of unplugging and plugging back in. Last time I only watched it for less than a minute.

Apr 20 19:13:22 atsuko systemd[300092]: Started kitty child process: 474915 launched by: 474903.
Apr 20 19:13:22 atsuko kernel: asus_wmi: Unknown key code 0xe5
Apr 20 19:13:25 atsuko kwin_wayland[300161]: kf.windowsystem: static bool KX11Extras::mapViewport() may only be used on X11
Apr 20 19:13:33 atsuko kernel: asus_wmi: Unknown key code 0xe5
Apr 20 19:13:43 atsuko kernel: asus_wmi: Unknown key code 0xe5
Apr 20 19:13:54 atsuko kernel: asus_wmi: Unknown key code 0xe5
Apr 20 19:14:01 atsuko systemd[300092]: app-kitty@45427a0119234ede9ba0a930e91a16ce.service: Consumed 275ms CPU time, 87.5M memory peak.
Apr 20 19:14:22 atsuko python3[300671]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Apr 20 19:14:22 atsuko python3[300671]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Apr 20 19:15:29 atsuko python3[300671]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Apr 20 19:15:29 atsuko python3[300671]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Apr 20 19:16:38 atsuko python3[300671]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed

Last edited by KorvinSilver (2025-04-22 08:05:38)

KorvinSilver · 2025-04-26 14:10:42

Well, it is the charger. It started again at night

Apr 26 01:57:22 atsuko kernel: asus_wmi: Unknown key code 0xe5
Apr 26 01:57:33 atsuko kernel: asus_wmi: Unknown key code 0xe5
Apr 26 01:57:43 atsuko kernel: asus_wmi: Unknown key code 0xe5
Apr 26 01:57:54 atsuko kernel: asus_wmi: Unknown key code 0xe5
Apr 26 01:58:04 atsuko kernel: asus_wmi: Unknown key code 0xe5

Checked on it just now with xev, unplugged the charger at 15:52:45, it stopped roughly a minute later and plugged the charger back at 15:54:30. Didn't come back immediately, so far it seems it takes three or four days.

Apr 26 15:52:29 atsuko kernel: asus_wmi: Unknown key code 0xe5
Apr 26 15:52:39 atsuko kernel: asus_wmi: Unknown key code 0xe5
Apr 26 15:52:50 atsuko kernel: asus_wmi: Unknown key code 0xe5
Apr 26 15:53:00 atsuko kernel: asus_wmi: Unknown key code 0xe5
Apr 26 15:53:00 atsuko python3[2199]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Apr 26 15:53:00 atsuko python3[2199]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Apr 26 15:53:11 atsuko kernel: asus_wmi: Unknown key code 0xe5
Apr 26 15:53:21 atsuko kernel: asus_wmi: Unknown key code 0xe5
Apr 26 15:53:23 atsuko rtkit-daemon[1686]: Supervising 13 threads of 8 processes of 1 users.
Apr 26 15:53:23 atsuko rtkit-daemon[1686]: Supervising 13 threads of 8 processes of 1 users.
Apr 26 15:53:32 atsuko kernel: asus_wmi: Unknown key code 0xe5
Apr 26 15:53:42 atsuko kernel: asus_wmi: Unknown key code 0xe5
Apr 26 15:53:48 atsuko python3[2199]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Apr 26 15:53:48 atsuko python3[2199]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Apr 26 15:54:25 atsuko rtkit-daemon[1686]: Supervising 13 threads of 8 processes of 1 users.
Apr 26 15:54:25 atsuko rtkit-daemon[1686]: Supervising 13 threads of 8 processes of 1 users.
Apr 26 15:54:56 atsuko python3[2199]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Apr 26 15:54:56 atsuko python3[2199]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Apr 26 15:55:26 atsuko rtkit-daemon[1686]: Supervising 13 threads of 8 processes of 1 users.
Apr 26 15:55:26 atsuko rtkit-daemon[1686]: Supervising 13 threads of 8 processes of 1 users.
Apr 26 15:55:45 atsuko python3[2199]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Apr 26 15:55:45 atsuko python3[2199]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Apr 26 15:55:59 atsuko kwin_wayland_wrapper[1718]: I2025-04-26 15:55:59.179497 instance.cpp:1232] Running autosave...
Apr 26 15:55:59 atsuko kwin_wayland_wrapper[1718]: I2025-04-26 15:55:59.181629 instance.cpp:1234] End autosave
Apr 26 15:56:28 atsuko rtkit-daemon[1686]: Supervising 13 threads of 8 processes of 1 users.
Apr 26 15:56:28 atsuko rtkit-daemon[1686]: Supervising 13 threads of 8 processes of 1 users.
Apr 26 15:56:54 atsuko python3[2199]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Apr 26 15:56:54 atsuko python3[2199]: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Apr 26 15:57:31 atsuko rtkit-daemon[1686]: Supervising 13 threads of 8 processes of 1 users.
Apr 26 15:57:31 atsuko rtkit-daemon[1686]: Supervising 13 threads of 8 processes of 1 users.

Well, there is at least some solution.

seth · 2025-04-26 16:17:25

See /usr/lib/udev/hwdb.d/60-keyboard.hwdb /usr/lib/udev/hwdb.d/60-keyboard.hwdb and https://wiki.archlinux.org/title/Map_sc … s#Examples and set "KEYBOARD_KEY_f8=unknown" (0xf8 == 248)

KorvinSilver · 2025-04-26 18:38:32

seth wrote:

See /usr/lib/udev/hwdb.d/60-keyboard.hwdb /usr/lib/udev/hwdb.d/60-keyboard.hwdb and https://wiki.archlinux.org/title/Map_sc … s#Examples and set "KEYBOARD_KEY_f8=unknown" (0xf8 == 248)

I could try, but why f8?

seth · 2025-04-27 06:03:18

seth wrote:

(0xf8 == 248)

OP wrote:

state 0x10, keycode 248 (keysym 0x0, NoSymbol), same_screen YES,

I suppose e5 (which already is "unknown") is just an accompanying symptom.

KorvinSilver · 2025-05-07 11:31:21

That hwdb rule didn't fix it, it started again today. 90 seconds off charger stopped it again.

seth · 2025-05-07 15:41:33

Do you still get the same xev event?
https://wiki.archlinux.org/title/Acpid
Does "sudo acpi_listen" recognize the event?

sudo evtest --grab <event device>

will suck away all events from that device, might cause collateral damage, though (eg. if the power button is there or so)

Arch Linux

#1 2025-04-20 14:10:05

[SOLVED] Phantom keypresses occurring every 10 seconds or so

#2 2025-04-20 17:04:20

Re: [SOLVED] Phantom keypresses occurring every 10 seconds or so

#3 2025-04-20 17:16:40

Re: [SOLVED] Phantom keypresses occurring every 10 seconds or so

#4 2025-04-21 06:30:52

Re: [SOLVED] Phantom keypresses occurring every 10 seconds or so

#5 2025-04-22 08:03:26

Re: [SOLVED] Phantom keypresses occurring every 10 seconds or so

#6 2025-04-26 14:10:42

Re: [SOLVED] Phantom keypresses occurring every 10 seconds or so

#7 2025-04-26 16:17:25

Re: [SOLVED] Phantom keypresses occurring every 10 seconds or so

#8 2025-04-26 18:38:32

Re: [SOLVED] Phantom keypresses occurring every 10 seconds or so

#9 2025-04-27 06:03:18

Re: [SOLVED] Phantom keypresses occurring every 10 seconds or so

#10 2025-05-07 11:31:21

Re: [SOLVED] Phantom keypresses occurring every 10 seconds or so

#11 2025-05-07 15:41:33

Re: [SOLVED] Phantom keypresses occurring every 10 seconds or so

Board footer