Bug 95030

I'm currently using libinput version 1.2.2. I don't see anything mentioned in the 1.2.3 changelog that makes me think this is addressed in 1.2.3.

I can now confirm it still happens with libinput v1.2.3.

record one of these hovering sequences with evemu-record and attach it here please, thanks.

ping?

I tried to make sure I only hovered and didn't touch the touchpad.

This is the log as captured by:

`sudo evemu-record /dev/input/event11 > bcm5974.log`

https://gist.githubusercontent.com/anonymous/7062945e0599195bec470ac1a2d58415/raw/dadda577c6a13fc8d644abf98035620c785a87cc/bcm5974.log

Created attachment 123555 [details]
touchpad.evemu

Please always attach files instead of linking to external sites.

ok, so we get BTN_TOUCH from the kernel but the major/minor axes look out of whack. can you submit a recording with a real touch for comparison please? A single short sequence of a pointer movement is sufficent

Created attachment 123556 [details]
evemu recording with contact

I executed: 'sudo evemu-record /dev/input/event11 > bcm5974.log'

Then I dragged my finger across the touchpad from left to right.

First thing I noticed: ABS_MT_TOUCH_MAJOR is not set when hovering. Can you confirm that? Piping evemu-record through "grep ABS_MT_TOUCH_MAJOR" should be enough to verify that (use unbuffer to avoid false positives caused by buffering)

I don't have unbuffer and couldn't easily acquire it, but evemu was outputting timestamps and I wasn't seeing anything buffered in a way that would affect my observations. Here's what I observed.

Hovering: no ABS_MT_TOUCH_MAJOR output

Touching with one finger: inconsistent results. I would get ABS_MT_TOUCH_MAJOR, but sometimes it would stop appearing for a second or two even though the cursor was moving.

Touching with two fingers: seemed like I saw the event more consistently, but there were still times when I would vertical scroll with two fingers. Chrome was certainly moving up and down a lot, but I had numerous gaps, a second, up to 5 seconds, where I wasn't seeing that event output, despite the cursor reacting as I would expect.

(In reply to Cole Mickens from comment #10)
> Hovering: no ABS_MT_TOUCH_MAJOR output

ok, that's good news then (I'll need to check the kernel driver to be sure though)

> Touching with one finger: inconsistent results. I would get
> ABS_MT_TOUCH_MAJOR, but sometimes it would stop appearing for a second or
> two even though the cursor was moving.

that is acceptable. the kernel buffers values, so if the major axis does not change then no events will be sent. and since the axis describes the size of the touchpoint it does not change too much while the finger pressure remains the same. Can you confirm though that the ABS_MT_TOUCH_MAJOR event comes as soon as you physically touch the touchpad? To detect this we only need one event, after that it doesn't matter (though it'd be interesting to see if it goes back to 0 or so on physical release)

>Can you confirm though that the ABS_MT_TOUCH_MAJOR event comes as soon as you physically touch the touchpad?

Yes. As soon as I make contact that event is emitted.

>(though it'd be interesting to see if it goes back to 0 or so on physical release)

I'm not sure how to tell if this is the case since evemu-record presents them as distinct events rather than a continuous value that I can watch "go back to 0", other than the fact that if I go from physical-contact to hovering, the event stops being output.

(In reply to Cole Mickens from comment #12)
> I'm not sure how to tell if this is the case since evemu-record presents
> them as distinct events rather than a continuous value that I can watch "go
> back to 0", other than the fact that if I go from physical-contact to
> hovering, the event stops being output.

pipe the evemu record into a file and search for the last occurrence of the event. Then check what that value is. Repeat a few times to see if there's any pattern.

This needs to be fixed in the kernel unfortunately. We could detect this in libinput, but it just does not make sense to detect all various bugs from the kernel. Here the kernel says that the device is touching while it is hovering, so it's a bug.

Please open a bug on https://bugzilla.kernel.org/, mentioning this one, and attach your recordings there too. Make sure to have the input component selected, and also reference the new bug here. I'll try to poke the various maintainers for this driver then.

I do not have any MacBook available for the tests, and I assume the required patch might affect other generations, so better have the actual maintainer handling this.

Regarding the pixel 2 mentioned in comment 0, there was a bug in both the kernel and libinput IIRC, and we fixed those in a timely manner, yes :)

Closing this for now, please re-open when the kernel fix is in and it still doesn't work in libinput