Keyd neuters libinput's "disable while typing" for touchpads

[canadaduane]

When using keyd to intercept keys on a laptop with a touchpad, the "disable while typing" feature is neutered: with keyd enabled and while typing, it is very common for the touchpad to emit a "BTN_LEFT" event aimed at wherever the mouse pointer happens to be hovering (I usually can't type two complete sentences without it happening).

[rvaiya]

A quick skim of the document posted yields this passage:

libinput pairs touchpads and keyboards for the disable-while-typing feature. In the most common case, the internal touchpad is paired only with the internal keyboard. Typing on an external keyboard will thus not disable the touchpad. Some devices require a quirk to be correctly paired.

Which would be consistent with the behaviour you are experiencing. keyd necessarily creates a virtual input device which libinput cannot distinguish from an external keyboard. You will probably need to explicitly inform it of the relationship between the devices as mentioned.

[canadaduane]

You will probably need to explicitly inform it of the relationship between the devices as mentioned.

That was my thought, too; however, I'm not quite sure how that would be done. Perhaps it would be on keyd to read whatever relationship the keyboard has in libinput and write the same relationship to the virtual keyboard created? (Again, I'm still learning here, so I'm not sure if that makes sense yet.)

[canadaduane]

Here's the libinput code where keyboards and touchpads are paired at the time they are added (see line 2597):

https://github.com/wayland-project/libinput/blob/10124797b502f3dd308919b7bab80752483d0f6b/src/evdev-mt-touchpad.c#L2591

Definition of tp_dwt_pair_keyboard here:

https://github.com/wayland-project/libinput/blob/10124797b502f3dd308919b7bab80752483d0f6b/src/evdev-mt-touchpad.c#L2358

[rvaiya]

Can't you just add a device quirk for keyd in /usr/share/libinput? It seems the primary issue is that you want to benefit from having libinput consider keyd an internal keyboard which is something that should be configurable (according to this page). keyd has no knowledge of/doesn't care about libinput. I assume the config would look something like this

[Serial Keyboards]
MatchUdevType=keyboard
MatchName="keyd virtual keyboard"
AttrKeyboardIntegration=internal

but I haven't tried it

[canadaduane]

It looks like if the product & vendor IDs match, they will be considered a pair:

https://github.com/wayland-project/libinput/blob/10124797b502f3dd308919b7bab80752483d0f6b/src/evdev-mt-touchpad.c#L2336

Can the virtual keyboard copy those? That probably has other implications...

[canadaduane]

Can't you just add a device quirk for keyd in /usr/share/libinput?

I'll give it a try and report back.

[rvaiya]

Can the virtual keyboard copy those? That probably has other implications...

I've considered making a separate virtual device for each input device with cloned products ids but it adds some additional complexity and may have unintended side effects. I would prefer to avoid this for now unless it solves a pressing problem.

[canadaduane]

may have unintended side effects

This marks at least one case where it would have a beneficial side effect.

It looks like I can use the workaround you suggested. Here is my final file:

/etc/libinput/local-overrides.quirks:

[Serial Keyboards]
MatchUdevType=keyboard
MatchName=keyd virtual keyboard
AttrKeyboardIntegration=internal

(Note that the lack of quotation marks is mandatory; docs here: https://wayland.freedesktop.org/libinput/doc/latest/device-quirks.html#device-quirks-local)

[canadaduane]

I feel like this is a very subtle "gotcha" that will be very painful for future users. It took me several weeks of digging to finally understand what was going on.

Edit: To be clear, there are three "aspects" to this "gotcha":

1. It only affects laptop users (well, and external touchpad users whose vendor/product ID match their keyboard...); libinput is ubiquitous
2. Users don't expect a service that remaps keys to also affect other devices such as the touchpad
3. Everything appears to work fine, so there are no alarm bells; it's only well into daily use--after installation and experimentation and mentally putting keyd behind--that this negative side effect crops up (i.e. while touch typing to write an email, for instance)

[canadaduane]

A more general discussion (outside of keyd-specific issues) here: linuxtouchpad/discussion#7

[rvaiya]

I feel like this is a very subtle "gotcha" that will be very painful for future users. It took me several weeks of digging to finally understand what was going on.

This sort of thing is par for the course when you use a low level remapping tool like keyd. Creating a dedicated virtual device for each input device and cloning the product/vendor ids is a tempting solution but it can easily cause bugs in other programs which don't expect multiple devices to have the same ids. It can also interfere with userspace driver tools which expect devices with a given vendor/product id pair to have device specific behaviours.

Id cloning may or may not be an issue in this particular instance, but in general a dedicated virtual device which behaves like a separate keyboard makes sense as the long as the user conceptually treats it like one.

What might make more sense generally (and would solve this particular problem) is to give keyd's virtual pointer the same id as its virtual keyboard os libinput treats them as an integreated unit when it manages hybrid devices.

I also agree that this should be better documented and intend to improve the FAQ section shortly. I have been preoccupied with a few other things, but I expect a 2.0 release within the next few days.

Related:

b8d6f5a (commit message)
#42 (comment)
#10

[canadaduane]

What might make more sense generally (and would solve this particular problem) is to give keyd's virtual pointer the same id as its virtual keyboard os libinput treats them as an integreated unit when it manages hybrid devices.

Interesting idea!

I also agree that this should be better documented and intend to improve the FAQ section shortly. I have been preoccupied with a few other things, but I expect a 2.0 release within the next few days.

That's exciting! Keep up the great work!

Related:

b8d6f5a (commit message)
#42 (comment)
#10

I saw #42 previously and read with interest. It can definitely be a jungle out there!

[rvaiya]

I believe this should no longer be an issue since everything was consolidated into a single virtual device. Can you confirm?

[canadaduane]

I've been testing a bit today and yesterday, and things are looking promising, but I'd like to test a bit more before giving it the all ok.

[rvaiya]

I've had to revert the change which fixed this, but I've replaced it with something which should have a similar effect. Can you confirm that this is no longer an issue with the latest commit?

[rvaiya]

Sorry, I was conflating this with #42. Though I've also just shipped a patch which should address this. The solution was just to ship a quirks file with keyd. I am closing this for now but feel free to open it if you have concerns.

[Apacelus]

@rvaiya I am having the same issue and I cant find that quirks file you mentioned