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

KorvinSilver · 2025-05-22 04:44:26

It took a moment to be able to do some testing again, and this is the result

sudo acpi_listen                     
wmi PNP0C14:02 000000ff 00000000
wmi PNP0C14:02 000000ff 00000000
wmi PNP0C14:02 000000ff 00000000

sudo evtest --grab /dev/input/event25
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: "Asus WMI hotkeys"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 113 (KEY_MUTE)
    Event code 114 (KEY_VOLUMEDOWN)
    Event code 115 (KEY_VOLUMEUP)
    Event code 140 (KEY_CALC)
    Event code 148 (KEY_PROG1)
    Event code 149 (KEY_PROG2)
    Event code 150 (KEY_WWW)
    Event code 152 (KEY_SCREENLOCK)
    Event code 163 (KEY_NEXTSONG)
    Event code 164 (KEY_PLAYPAUSE)
    Event code 165 (KEY_PREVIOUSSONG)
    Event code 166 (KEY_STOPCD)
    Event code 169 (KEY_PHONE)
    Event code 183 (KEY_F13)
    Event code 185 (KEY_F15)
    Event code 202 (KEY_PROG3)
    Event code 203 (KEY_PROG4)
    Event code 212 (KEY_CAMERA)
    Event code 215 (KEY_EMAIL)
    Event code 224 (KEY_BRIGHTNESSDOWN)
    Event code 225 (KEY_BRIGHTNESSUP)
    Event code 226 (KEY_MEDIA)
    Event code 227 (KEY_SWITCHVIDEOMODE)
    Event code 229 (KEY_KBDILLUMDOWN)
    Event code 230 (KEY_KBDILLUMUP)
    Event code 237 (KEY_BLUETOOTH)
    Event code 238 (KEY_WLAN)
    Event code 240 (KEY_UNKNOWN)
    Event code 247 (KEY_RFKILL)
    Event code 248 (KEY_MICMUTE)
    Event code 470 (KEY_FN_F5)
    Event code 530 (KEY_TOUCHPAD_TOGGLE)
    Event code 531 (KEY_TOUCHPAD_ON)
    Event code 560 (KEY_ALS_TOGGLE)
    Event code 634 (?)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Key repeat handling:
  Repeat type 20 (EV_REP)
    Repeat code 0 (REP_DELAY)
      Value    250
    Repeat code 1 (REP_PERIOD)
      Value     33
Properties:
Testing ... (interrupt to exit)
Event: time 1747888647.504433, type 4 (EV_MSC), code 4 (MSC_SCAN), value e5
Event: time 1747888647.504433, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1747888647.504433, -------------- SYN_REPORT ------------
Event: time 1747888647.504437, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1747888647.504437, -------------- SYN_REPORT ------------
Event: time 1747888658.025679, type 4 (EV_MSC), code 4 (MSC_SCAN), value e5
Event: time 1747888658.025679, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1747888658.025679, -------------- SYN_REPORT ------------
Event: time 1747888658.025684, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1747888658.025684, -------------- SYN_REPORT ------------
Event: time 1747888668.549873, type 4 (EV_MSC), code 4 (MSC_SCAN), value e5
Event: time 1747888668.549873, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1747888668.549873, -------------- SYN_REPORT ------------
Event: time 1747888668.549875, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1747888668.549875, -------------- SYN_REPORT ------------
Event: time 1747888679.072761, type 4 (EV_MSC), code 4 (MSC_SCAN), value e5
Event: time 1747888679.072761, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1747888679.072761, -------------- SYN_REPORT ------------
Event: time 1747888679.072766, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1747888679.072766, -------------- SYN_REPORT ------------

evtest detects it on event25

Oh, and keyboard input being interrupted isn't related to this, that happens independently. I suspect my keyboard is the issue but I'll open another thread if it isn't and I can't figure that one out.

Last edited by KorvinSilver (2025-05-22 04:50:07)

seth · 2025-05-22 06:46:16

So the charger events are still there but harmless (evtest --grab would completely suck them away from the rest of the system) and a red herring for the actual keyboard disfunction?
Do you have an external keyboard and can you leave the internal one alone for a while?
(Might be a physical issue where keys get stuck)

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

#12 2025-05-22 04:44:26

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

#13 2025-05-22 06:46:16

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

Board footer