Summary: | BTN_TOOL_* are not handled properly when 2 are set/unset in the same frame | ||
---|---|---|---|
Product: | Wayland | Reporter: | Benjamin Tissoires <benjamin.tissoires> |
Component: | libinput | Assignee: | 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 |
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. 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. 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 (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. 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.
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.