Uinput: keyboard shortcuts

[iansw246]

Summary of changes

Support keyboard shortcuts when Plover is enabled and using Uinput. Currently, keyboard shortcuts such as Ctrl-C are captured and not handled correctly. With this change, any keys pressed while a modifier key is pressed, or before all keys part of modifier sequence are released, will be passed through. This matches the behavior on Windows. This change also enables the use of the global Plover toggle command (PHROLG) when Plover is disabled.

Furthermore, these input handling changes fix two issues:

1. Input events that are not EV_KEY (such as EV_MSC) are passed through as EV_KEY, causing spurious inputs on some keyboards.

2. Key repeat events are treated as key releases. On my laptop, this results in strokes being prematurely finished while I still have one key being held.

These changes are based off code in #1760, so that should be merged first.

Pull Request Checklist

• Changes have tests
• News fragment added in news.d. See documentation for details

[mkrnr]

The changes look good to me, thank you! I wasn't able to reproduce the original issue with my setup. Can you give me some information about your setup so I can test this in the future?

Also, the PR is ready from your side? I'll then go ahead and merge.

[user202729]

reading the keyboard description I think this addresses the issue numbered (4) in #1707 .

I think the news.d files usually end with a full stop.

Would be nice if there's unit test for these things, although that can be left for later. It feels like this code has already been done somewhere (does the code for Windows/Mac have this logic?), but it's not very necessary to address this either.

If the user maps caps lock to control (not sure how to do it on wayland, on X I do setxkbmap -option caps:ctrl_modifier), does holding caps lock get treated the same way as holding ctrl?

[iansw246]

I am using my HP Laptop's built-in keyboard with Fedora 42 (Linux 6.15.10) and KDE Plasma 6.4.4.

I've been able to somewhat inconsistently reproduce the issue in VSCode and Vivaldi (maybe related to Chromium?) by reconnecting the keyboard machine in Plover, entering any stroke, then alt tabbing to another program and then back to the first program. The character '3' will be entered repeatedly as if the 3 key is always being held down. Sometimes, the issue also occurs, even with Plover disabled, when typing in another program and alt tabbing to the affected programs.

Below is a log of all events capture by Evdev on my laptop. Notice how before every key event, there is another event with code 04, type 04. Type 4 is EV_MSC, and code 4 is MSC_SCAN. The current code treats EV_MSC these as key presses.

event at 1756038497.471467, code 04, type 04, val 35
key event at 1756038497.471467, 35 (KEY_H), down
synchronization event at 1756038497.471467, SYN_REPORT
event at 1756038497.528080, code 04, type 04, val 23
key event at 1756038497.528080, 23 (KEY_I), down
synchronization event at 1756038497.528080, SYN_REPORT
event at 1756038497.559869, code 04, type 04, val 35
key event at 1756038497.559869, 35 (KEY_H), up
synchronization event at 1756038497.559869, SYN_REPORT
event at 1756038497.629927, code 04, type 04, val 23
key event at 1756038497.629927, 23 (KEY_I), up
synchronization event at 1756038497.629927, SYN_REPORT

capture from this test script:

import evdev

device = evdev.InputDevice("/dev/input/event3")
for event in device.read_loop():
    print(evdev.categorize(event))

[iansw246]

I did base these changes off the Windows code. There is some duplication of the logic between Windows.

The code relies on scancodes, so key mapping in X11 or Wayland has no effect, unfortunately; the keyboard shortcut functionality will not work with caps lock. Using the keymaps from these higher levels would fix this issue and most of the keyboard layout issues. In the meantime, one possibility is to add an option to configure which scancodes are treated as modifier keys