With an HP x3 Lap Dock accessory, clicks with the clickpad are ignored while the touchpad is working fine otherwise. Tap clicks are working as expected but physical clicks are not triggering any events at all. I can see raw events upon physical clicks with the clickpad in the HID raw output of the right device in /dev/hidrawX. However, there is no corresponding event reported at all for physical clicks with evtest or evemu-record, while other actions (tapping, moving, etc.) are showing in the output properly. The HID raw output is consistent and 100% reproducible, with one small set of events for physical clicks on the bottom left corner: # hexdump -C hidraw_single_bottom_left_physical_click 00000000 01 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 |................| 00000010 00 00 |..| and another set for physical clicks the bottom right corner: # hexdump -C hidraw_single_bottom_right_physical_click 00000000 01 02 00 00 00 00 00 00 00 01 00 00 00 00 00 00 |................| 00000010 00 00 |..| The touchpad doesn't detect finger touch in the bottom left and right corners so the HID raw output is small in these cases; when clicking outside of these 2 zones, the output is mixed with touch events. It seems that BTN_LEFT and BTN_RIGHT events are not generated for this hardware, it maybe needs a quirk or a specific code to detect these HID raw events. The clickpad on this touchpad has never worked, as far as I know, and I've tested on a quite quite recent Linux kernel built from drm-tip (5.1.0-rc1.20190321). I'll provide some logs / outputs below, feel free to ask for some more.
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