Bug 203181
Summary: | HP x3 Lap Dock clickpad not generating BTN_LEFT and BTN_RIGHT events | ||
---|---|---|---|
Product: | Drivers | Reporter: | Jérôme de Bretagne (jerome.debretagne) |
Component: | Input Devices | Assignee: | drivers_input-devices |
Status: | RESOLVED CODE_FIX | ||
Severity: | normal | CC: | benjamin.tissoires, peter.hutterer |
Priority: | P1 | ||
Hardware: | Other | ||
OS: | Linux | ||
Kernel Version: | 5.0 5.1 5.2 5.3 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
dmesg extract
xinput list xinput list-props evemu-describe hidraw_single_bottom_left_physical_click hidraw_single_bottom_right_physical_click hid-recorder bottom_left hid-recorder bottom_right hid-recorder 4_other_captures |
Description
Jérôme de Bretagne
2019-04-07 14:59:19 UTC
Created attachment 282161 [details]
dmesg extract
Here is a small extract of dmesg
Created attachment 282163 [details]
xinput list
Here is the output of xinput list
Created attachment 282165 [details]
xinput list-props
Here is the ouput of xinput list-props on the right touchpad.
Created attachment 282167 [details] evemu-describe Here is the output of evemu-describe. It only lists BTN_LEFT and not BTN_RIGHT, while the hardware is generating dedicated events separately for the bottom left and bottom right corners. By the way, this device didn't always behave this way, as support for touchpad physcial clicks (and drag and drop) was added in the latest firmware revision T0057 (which my unit is running) as described here for instance: https://www.windowscentral.com/new-firmware-hp-lap-dock-touchpad Created attachment 282169 [details]
hidraw_single_bottom_left_physical_click
The HID raw output from a single click in the bottom left corner:
# cat /dev/hidraw5 > hidraw_single_bottom_left_physical_click
Created attachment 282171 [details]
hidraw_single_bottom_right_physical_click
The HID raw output from a single click in the bottom right corner:
# cat /dev/hidraw5 > hidraw_single_bottom_right_physical_click
As suggested by Peter in https://gitlab.freedesktop.org/libinput/libinput/issues/264, I'm attaching captures taken with hid-recorder to share the HID reports. Created attachment 282177 [details]
hid-recorder bottom_left
Here is the capture of a single physical click in the bottom left corner
Created attachment 282179 [details]
hid-recorder bottom_right
Here is the capture of a single physical click in the bottom right corner
Created attachment 282181 [details]
hid-recorder 4_other_captures
Finally, here are 4 captures of a single physical click in 4 other regions:
- bottom center
- top left
- top center
- top right
In those 4, there is no clear reference to a button press it seems, as opposed to the content of the previous 2 captures in the bottom corners.
Benjamin: looks like the buttons come in as Report ID 1 (Mouse) and still as left/right button presses there, even though the device uses the touchpad mode otherwise. All the data from comment 10 comes in via Report ID 4 (Touchpad). Evemu record from the libinput bug says: Kernel: 5.1.0-rc1.20190321.01-drm-tip+ I guess this is one more reason to not filter out the mouse node on touchpads. The only thing I am not that happy about is that this touchpad doesn't even expose itself as a Win8 Precision Touchpad. So that means I should enable the mouse node for everybody, and hope that Win7 touchscreens are a thing of the past. This HP model was indeed described as *not* having a Precision Touchpad when launched, for instance in this review: https://m.windowscentral.com/hp-lap-dock-review Hi Benjamin, hi Peter, I've just recently seen Benjamin's patch, proposed here a few weeks ago: https://patchwork.kernel.org/patch/11090121/ [1/2] HID: multitouch: do not filter mice nodes and it seemed to me somehow related to the point discussed in comment 12. So I've compiled a newer kernel with this small change applied and I'm happy to report that the physical clicks on the HP x3 Lap Dock are now working perfectly: left and right single-clicks, double-clicks, click-and-drag, etc. Thanks so much. I'll close this bug once the patch is officially merged upstream, hopefully in kernel 5.4.0 Jérôme P.S. My kernel build is based on drm-tip, for other reasons, 5.3.0+ on commit 2019y-09m-16d-21h-12m-08s for reference. I can confirm that this issue is now fixed in kernel 5.4.0 , thanks again. Jérôme |