[Wayland-bugs] [Bug 99914] Combined Keyboard+Mouse+Touchpad device problems

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99914

--- Comment #9 from Gergely Nagy <freedesktop at gergo.csillger.hu> ---
(In reply to Peter Hutterer from comment #7)

> for all absolute events, libinput scales it based on the abs min/max values.
> without BTN_TOOL_FINGER, the device won't be recognised as touchpad and
> default to absolute pointer (similar to e.g. VM virtual mouse). That should
> work with libinput, but the libinput xorg driver (should) ignore the abs
> events then, it can only handle one type of pointer. once you add
> BTN_TOOL_FINGER it'll be a touchpad and you'll lose the rel bits (and key
> bits).

Yeah, the abs events are ignored, that's why I tried to hack the xorg driver a
bit, to at least let it through.

So, if I understand correctly, if I separated the rel & abs mouse stuff, into
two different nodes, then both of them should work? (Assuming the absolute
mouse part reports itself properly)

> all that aside, run libinput-debug-events for testing, that's easiest to
> figure out what libinput does.
> The output here for the new recording is:
> -event7   DEVICE_ADDED     Shortcut Shortcut  seat0 default group10 cap:kp
> left scroll-nat calib scroll-button
>  event7   POINTER_MOTION_ABSOLUTE  +1.99s     25.00/ 25.00
>  event7   POINTER_MOTION_ABSOLUTE  +3.90s     74.99/ 25.00
>  event7   POINTER_MOTION_ABSOLUTE  +6.13s     25.00/ 74.99
>  event7   POINTER_MOTION_ABSOLUTE  +8.02s     74.99/ 74.99
> 
> The numbers are relative to 100, so 75 means 75% of the axis.

Sounds like this part is allright then!

> btw, you don't have an axis resolution set, that's not good for an absolute
> device.

Mhm. Will try to figure out what these should be set to, thanks!

> The Xorg.log says:
>   
>   Feb 23 19:29:37 jelly /usr/libexec/gdm-x-session[10694]: (EE) libinput:
> Shortcut Shortcut: Discarding absolute event from relative device. Please
> file a bug
> 
> so the device is detected, but xf86-input-libinput cannot handle both
> relative and absoluute at the same time. That's a known bug, I tried to fix
> that the other way but aside from your device there isn't really a true need
> for it right now :)

There are two keyboards in the making with this firmware (the Shortcut[0], and
the Keyboardio Model 01[1]), with hopefully more to follow. If you think it
would be worth it, I can try digging into xf86-input-libinput, to try and add
support for both abs and rel devices. If not, then I'll try to make the
firmware report the two parts as two nodes.

(In reply to Peter Hutterer from comment #8)
> (In reply to Gergely Nagy from comment #6)
> > Some more data points: I've been staring at xf86-input-libinput, and noticed
> > that it sets the axis max to 0xffff for absolute devices.
> 
> yes, that's a side-effect of the xserver design, we need to have the full
> axis range, but libinput doesn't provide that one ahead of time. So we just
> map to a range of [0, 0xffff] instead and transform the coordinates to that
> (see xf86libinput_handle_absmotion). There shouldn't be a scaling bug since
> it works for libinput directly. The real problem is likely that the device
> gets set up as relative device and then the server gets confused when you
> send absolute events. I don't know off-heart what the server uses for
> scaling in that case.

Looks like it will just treat absolute coordinates as screen coordinates 1:1,
but I'll dig deeper.

> Either way, a few well-placed ErrorF() should help (works like printf)

Thanks!

> > so perhaps the
> > problem is being on the same node and/or not having the BTN_TOUCH_* flags?
> 
> if it is just an absolute pointing device and not a real touchpad, you
> shouldn't have BTN_TOUCH or BTN_TOOL_FINGER, so you're good there. But
> having real+abs on one node just wont' work (yet) because of
> xf86-input-libinput limitations.

Understood. So, it appears this is not a libinput thing, but an
xf86-input-libinput limitation. And there are two options going forward:

- Report the keyboard+mouse parts as one device, absmouse as another, and hope
for the best.
- Improve xf86-input-libinput to handle the rel+abs on the same node case.

Either way, this issue is not with libinput, and can be closed, I suppose.
Thanks a lot for your help, it's much clearer now how this whole thing works!
I'll experiment with both options, and if it comes to that, will open an issue
on xf86-input-libinput.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20170223/942a6e6a/attachment-0001.html>