<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Improve Surface Pro Type Cover 2 support" href="https://bugs.freedesktop.org/show_bug.cgi?id=99079#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Improve Surface Pro Type Cover 2 support" href="https://bugs.freedesktop.org/show_bug.cgi?id=99079">bug 99079</a> from <a class="email" href="mailto:defree@gmail.com" title="defree@gmail.com">defree@gmail.com</a> <pre>(In reply to Peter Hutterer from <a href="show_bug.cgi?id=99079#c2">comment #2</a>) > (In reply to defree from <a href="show_bug.cgi?id=99079#c0">comment #0</a>) > > ## Problems > > > > Spurious KEY_F23 event when clicking (that is a single click produces mouse > > button + keypress events). (+ pad disabled notification) > > if you see KEY_F23 then that's a hardware issue. something isn't initialized > correctly by the kernel, libinput doesn't generate those by itself. Yes that's what I expected. Fyi, here are various dumps of a click: usbhid-record 002:010:002:STREAM 1482233549.032873 01 00 72 00 00 00 00 00 00 00 00 00 002:010:002:STREAM 1482233549.034870 02 01 00 00 00 00 002:010:002:STREAM 1482233549.052872 01 00 00 00 00 00 00 00 00 00 00 00 002:010:002:STREAM 1482233549.420859 02 00 00 00 00 00 evemu-record E: 2.422037 0004 0004 458866 # EV_MSC / MSC_SCAN 458866 E: 2.422037 0001 00c1 0001 # EV_KEY / KEY_F23 1 E: 2.422037 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +2422ms E: 2.424030 0004 0004 589825 # EV_MSC / MSC_SCAN 589825 E: 2.424030 0001 0110 0001 # EV_KEY / BTN_LEFT 1 E: 2.424030 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +2ms E: 2.441998 0004 0004 458866 # EV_MSC / MSC_SCAN 458866 E: 2.441998 0001 00c1 0000 # EV_KEY / KEY_F23 0 E: 2.441998 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +17ms E: 4.794013 0004 0004 589825 # EV_MSC / MSC_SCAN 589825 E: 4.794013 0001 0110 0000 # EV_KEY / BTN_LEFT 0 E: 4.794013 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +2353ms So this device need some hack for proper support? Either a custom initialization procedure or just filtering some packets. (Is it reasonable to expect that kind of hack into the kernel? Given the huge number of clunky usb devices, it seems one would need a dedicated database for handling that). > > Clunky scroll: > > - not always detected > > - take time to start then scroll by one big chunk > > > > No tap and drag feature, this is critical for usability. > > is the touchpad detected as a touchpad or just as a mouse-like device? If > the former, you'll have to enable tapping, libinput has it disabled by > default. Here is the report by libinput-list-devices, I should have thought about sending that earlier sorry: Device: MICROSOFT SAM Kernel: /dev/input/event10 Group: 5 Seat: seat0, default Capabilities: keyboard pointer Tap-to-click: n/a Tap-and-drag: n/a Tap drag lock: n/a Left-handed: disabled Nat.scrolling: disabled Middle emulation: disabled Calibration: n/a Scroll methods: button Click methods: none Disable-w-typing: n/a Accel profiles: flat *adaptive Rotation: n/a Note that tap to click works as expected, it is the tap and drag which is not available (I cannot enable it with xinput either). (If I understand correctly, keyboard and touchpad are exposed by the same device, this seems confirmed by the evemu-record and usbhid-dump's). > an evemu-record of a scroll sequence should tell us what's going on there. Using usbhid-dump, I can see that the touchpad doesn't send anything for a few hundred milliseconds when scrolling. I guess it is just low quality touchpad, there is not much to do to fix that (this could match complains I have heard from Windows users). For information, here is a scroll sequence recorded, normal I guess: E: 0.731920 0002 0000 -001 # EV_REL / REL_X -1 E: 0.731920 0002 0001 0003 # EV_REL / REL_Y 3 E: 0.731920 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +731ms E: 0.829912 0002 0001 0001 # EV_REL / REL_Y 1 E: 0.829912 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +98ms E: 0.841890 0002 0001 0001 # EV_REL / REL_Y 1 E: 0.841890 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 0.872882 0002 0001 0001 # EV_REL / REL_Y 1 E: 0.872882 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +31ms E: 0.886920 0002 0001 0001 # EV_REL / REL_Y 1 E: 0.886920 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +14ms > > # Touchscreen > > > > usb-id: 03eb:8209 Atmel Corp. > > libinput-name: Atmel Atmel maXTouch Digitizer > > > > ## Problem > > > > I am not familiar with touchscreen, so maybe the behavior I am about to > > describe is normal and the bug elsewhere. > > > > A sequence for a click is TOUCH_DOWN, TOUCH_FRAME, TOUCH_UP. > > During motion, every TOUCH_MOTION is interleaved with a TOUCH_FRAME. > > yeah, that's correct and is the expected behaviour. TOUCH_FRAME is needed to > group frames. either way, short answer here is: touchscreen gestures like > tap-to-click is something that needs to be performed on the client-side, > i.e. in the application. recent GNOME3 should do this but otherwise it > depends on the toolkit. Ok, I will adjust desktop environment then. Thank you.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>