hp-x2-210-g2 Touchpad failure: POINTER_MOTION_ABSOLUTE, kpminus

[tkna91]

This is a strange problem with a 2-in-1 tablet laptop hp-x2-210-g2 that was sold by HP Japan.

It seems a bit complicated, so please let me know if there is any information needed. Maybe it has something to do with the touch display. https://jp.ext.hp.com/notebooks/business/hp_x2_210_g2_camera/

keyd-git 2.4.2.r74.1f3a780-1

1. the pointer warps (POINTER_MOTION_ABSOLUTE) when touching the touchpad
2. touching the touchpad causes "kpminus" to be entered

https://user-images.githubusercontent.com/102382754/191412611-86724ae9-d583-4554-95c7-8dc23463eb8e.mp4

Occurs in keyd-git 2.4.2.r74.1f3a780-1 and not in the stable version (keyd 2.4.2-1).

$ paru -Q keyd-git sway wlroots
keyd-git 2.4.2.r74.1f3a780-1
sway-git r6961.cffb006f-1
wlroots-git 0.16.0.r5714.ebd4c83c-1
$ 

Device list in keyd monitor

device added: 06cb:17ad SYNP1000:00 06CB:17AD (/dev/input/event18)
device added: 06cb:17ad SYNP1000:00 06CB:17AD Stylus (/dev/input/event17)
device added: 04f3:0755 HID 04f3:0755 (/dev/input/event6)
device added: 04f3:0755 Elan Touchpad (/dev/input/event5)
device added: 04f3:0755 HID 04f3:0755 (/dev/input/event4)

Only the touchpad 04f3:0755 is listed in [ids] in the keyd configuration. Device 06cb:17ad is not a touchpad, but a touch display.

/etc/keyd/test.conf

[ids]
04f3:0755

keyd monitor -t

+0 ms   Elan Touchpad   04f3:0755       kpminus down
+0 ms   Elan Touchpad   04f3:0755       numlock down
Unrecognized EV_ABS code: 24
Unrecognized EV_ABS code: 58
Unrecognized EV_ABS code: 24
Unrecognized EV_ABS code: 57
+0 ms   Elan Touchpad   04f3:0755       kpminus up
+0 ms   Elan Touchpad   04f3:0755       numlock up
Unrecognized EV_ABS code: 24

libinput debug-events

-event22  POINTER_MOTION_ABSOLUTE +2184.910s     42.15/ 57.07

libinput debug-events when keyd is not running

 event5   GESTURE_HOLD_BEGIN      +323.305s     1
 event5   GESTURE_HOLD_END        +323.321s     1

stable-keyd (keyd 2.4.2-1)

Doesn't seem to be a problem.

https://user-images.githubusercontent.com/102382754/191412683-b0c9d1c4-7ad8-4168-aae4-f93a3967bc97.mp4

[rvaiya]

Can you post the output of keyd itself using the latest commit? Also set KEYD_DEBUG=2 (E.g make && sudo KEYD_DEBUG=2 ./bin/keyd)

[tkna91]

I have attached the relevant logs.

keyd-20220921-231144.log

https://user-images.githubusercontent.com/102382754/191574750-93dc6092-7a83-477b-89ba-73821c005dcd.mp4

[rvaiya]

Sorry, I should have mentioned touchpads are currently unsupported. Adding support for this is non-trivial since a lot of work needs to be done on the raw touch events to make them usable (which is why libinput exists). I was aware of this when I originally added mouse support ,but forgot to make a note of it in the man page. I might add some preliminary support for it later.

[tkna91]

It would be nice if we could put only the keyboard (event4) under keyd control and exclude the other touchpads (event5), etc., but this does not seem possible because both have the same id 04f3:0755. It would be nice if some identifier could be used to separate them, such as event4 or HID 04f3:0755, how do you feel?

[rvaiya]

I probably should have added some kind of special prefix to distinguish mice to begin with. At this point it would be a breaking change, but it might be worth doing anyway since there isn't really good alternative. It is worth noting that if you use the wildcard id (*) it won't match any mice by default.

E.g:

[ids]
*
-<excluded keyboard>

[tkna91]

Personally, that method worked for me anyway. I use a tool called yadm to share *.conf in keyd with each environment, and if I rename hp1.conf to hp1.conf##hostname.hp1 and share it, the following symbolic link is created with just hostname hp1.

hp1.conf -> hp1.conf##hostname.hp1

https://yadm.io/docs/alternates

I was able to avoid the problematic phenomenon by including the following setting here.

[ids]
*

It worked in my case, but if there are no cases where the boundary between keyboard and pointing device is blurred in general, it may be fine as it is now.

[tkna91]

Thinking about it some more, I think it would be best if we could target "keyboards with 04f3:0755" by using some kind of identifier representation, but non-target "devices other than keyboards with 04f3:0755".

[rvaiya]

I've added some device type prefixes (m: and k:) to the latest commit. Let me know how you get along with them.

[tkna91]

Thanks! The k:04f3:0755 works as expected. I thought it would be more comprehensive in terms of setting targets if I could also exclude them with -m:04f3:0755 and so on. How do you feel about this?

[rvaiya]

* only matches keyboards by default, so -m:* is unnecessary. In general, mouse support is quite limited and should be avoided unless strictly necessary. I have been meaning to add some clarification in the man page.

[tkna91]

Understood. Thank you👍

[kooskaspers]

I've added some device type prefixes (m: and k:) to the latest commit. Let me know how you get along with them.

Thanks a million. I was already filing a bug at the libinput project :sweat_smile:. My cursor was jumping around as well, when using the trackpad. Would be good to add this the the readme as well. It's included:

If a vendor/product pair matches more than one device type, the prefix k: may be used to exclusively match keyboards and the prefix m: may be used to exclusively match mice. (E.g m:046d:b01d)

[carlosvigil]

Not sure how I missed the prefixing, but for what it's worth I had this same issue and found it difficult to discover.