Bug 99079

In "clunky scroll" I refer to two fingers scrolling.

(In reply to defree from comment #0)
> ## 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.

> 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.

an evemu-record of a scroll sequence should tell us what's going on there.


> # 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.

(In reply to Peter Hutterer from comment #2)
> (In reply to defree from comment #0)
> > ## 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.

(In reply to defree from comment #3)
> 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).

yes. CC-ing benjamin, he's done work on the type covers before and knows the current state.

as for tap-to-click and scrolling: the device just looks like a normal mouse with a scroll wheel. tapping is implemented in the firmware, we don't have access to it. here too we'd need the kernel to support this properly and expose it as a touchpad device.

We can put a quickfix in for the F23 though. In libinput's
evdev_pre_configure_model_quirks() put in a call to 

   libevdev_disable_event_code(device->evdev, EV_KEY, KEY_F23);

and see if that has any side-effects. as you noticed, F23 is used for touchpad disabling, so let's see what happens if we just completely filter this out.

Filtering F23 works quite well.
Afaict, only effect is to remove the touchpad disabled notification, it is much more comfortable.

update: benjamin thinks this should be fixed with v4.1 where the type cover is switched to proper multitouch. If you could confirm this with a pre-release kernel that'd be great.

First, about the touchscreen problem, I confirm it is related to handling of events higher in the stack (works fine with a clean gnome-shell 3.22, fails under some circumstances with other GTK apps or Chrome...). Solved as far as input system is concerned :).

I tested with 4.10-rc2 (not manually built but taken from Manjaro's unstable repository). Behavior is quite chaotic. I will try to summarize:
- regression on suspend/resume (4.9 release has the best/correct behavior)
- USB initialization is indeed different, but unreliable.

Cursor behavior is changed:
1) Tap-to-click no longer works (but according to our discussion, it used to be hardware emulation).
2) Movement is still relative but in a weird way. As if coordinates delta were interpreted in a wrong system (the closest I felt was with a wacom mouse which movement was interpreted relative to the tablet and not to the orientation of the mouse itself).
3) Yet libinput-list-devices and xinput list-props reports are the same.

Furthermore, on kernel side device initialization works rarely:
- I have to plug/unplug many times or reboot the device to get it initialized.
- after being initialized with 4.10 kernel, the changes in behavior survive a reboot and change to kernel 4.9. I have to unplug the usb or power off the system to get back to the clean behavior.

This "reboot survival" surprised me the most but I was able to reproduce multiple times.

can you give me an evemu-record for a tap and a movement sequence please? Thanks.

Today I tried with a kernel 4.10.0 (with manjaro patches, previous tests were on a custom built 4.10rc2), libinput 1.6.1.

All new bugs I complained about are gone (tap-to-click works again, movement are corrects again, and the unrelated suspend-and-resume bug is fixed).

The rest didn't change much: device initialization is still chaotic, most settings are unavailable/fixed by touchpad (no tap-to-drag, etc).

So more or a less a status quo.

To get a comfortable experience, I still have to patch kernel with usb quirks and libinput to filter F23. It is pretty decent with these settings.

Created attachment 129880 [details]
evemu record log of movement on 4.10

The movement recording you asked for.

Created attachment 129881 [details]
evemu record log of tap on 4.10

The tap record you asked for.

sorry for the delay. the two evemu records show relative movement only, so the device is not properly initiated as touchpad on this kernel

closing this, mostly so I don't keep looking at this bug when there's nothing we can do in libinput. Benjamin, anything you actually need from this bug? Or can we move this to the kernel?

IIRC  the surface 2 cover had a wrong HID report descriptor. I am not sure about the F23 key but I wouldn't be surprised if this was related to it too.

I don't want to fix bad report descriptors in hid-multitouch, because that would just open a can of worms. So the status quo is a little bit disappointing, but I don't want to spend too much time fixing a 4 year old device.

If someone has the time to do it, I think it should be done in hid-microsoft.