Bug 96182

Summary: BTN_TOOL_* are not handled properly when 2 are set/unset in the same frame
Product: Wayland Reporter: Benjamin Tissoires <benjamin.tissoires>
Component: libinputAssignee: Wayland bug list <wayland-bugs>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: medium CC: peter.hutterer
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: surface_pen_v4.evemu

Description Benjamin Tissoires 2016-05-25 09:19:50 UTC
Created attachment 124080 [details]
surface_pen_v4.evemu

On the surface pen current WIP, the BTN_TOOL_PEN/BTN_TOOL_RUBBER can be set and unset at the same time (see the 2 last events in the attached recording).

Libinput doesn't handle this gracefully and forgets to send the tool_rubber out of prox event.
Comment 1 Peter Hutterer 2016-05-30 06:11:19 UTC
AIUI this was fixed in the kernel driver now, so I'll just close this as WONTFIX until we have a device where we def. need it.
Comment 2 Benjamin Tissoires 2016-05-31 15:03:16 UTC
IIRC, the idea was to detect those on libinput and output a warning requesting a kernel fix. Or at least integrate this in the test suite so we are aware of it.
Comment 3 Peter Hutterer 2016-06-01 01:38:00 UTC
yeah, but I'm also using the current behaviour for all the tests that don't use the pen tool :) So I'd have to rewrite all of those
Comment 4 Benjamin Tissoires 2016-06-01 07:18:30 UTC
(In reply to Peter Hutterer from comment #3)
> yeah, but I'm also using the current behaviour for all the tests that don't
> use the pen tool :)

I am honestly not sure what you mean by that, so I'll just say: "fair enough" :)


> So I'd have to rewrite all of those

That I get. Anyway, not a big deal.
Comment 5 Peter Hutterer 2016-06-01 07:22:43 UTC
https://cgit.freedesktop.org/wayland/libinput/tree/test/tablet.c#n963, the proximity_range_enter test is one example. This test uses libinput's behaviour to only look at the most recent tool so we can send a proximity in followed by BTN_TOOL_MOUSE in the same frame and rely on the mouse being set.

This works because we don't have any actual device state before the tool is selected. There should be a more sensible approach but as I said this requires more rewrite than I have time for right now

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.