[PATCH libinput] evdev: allow weird multitouch device without slots

[Leonid Borisenko]

2014-08-19 10:02 GMT+03:00 Peter Hutterer <peter.hutterer at who-t.net>:

> On Tue, Aug 19, 2014 at 06:29:40AM +0300, Leonid Borisenko wrote:
> > HID device 'USB HID v1.11 Mouse' provided by Microsoft Wireless Optical
> > Desktop=C2=AE 2.20 (connected to USB and identified as vendor 0x45e, pr=
oduct
> > 0xe3, version 0x111) is reported as supporting EV_ABS event with
> ABS_MT_SLOT
> > code, but nevertheless libevdev_get_num_slots returns -1.
>
> yeah, that's intentional. libevdev detects those devices (through
> guesswork,
> but still...) and returns -1 as slot number.
>
> > Furthermore, all connected devices (mouse and keyboard) don't produce a=
ny
> > EV_ABS events for that HID Mouse device in tests with evtest.
> >
> > Before this fix mouse didn't work in Weston (but worked in X.Org).
> >
> > As partially explained by LKML message [1] (Message-Id [2]):
> >
> > The root of the problem comes from hid-input, which maps unknown ax=
is
> > to ABS_MISC. However, when an event code is already in use, hid-inp=
ut
> > uses the one after, leading to uses of ABS_MISC + N, where N is the
> > number of unknown axis.
> >
> > We are encountering a problem with the multitouch protocol here
> because
> > if a device has more than 7 unknown axis (which is the case for the
> PS3
> > Sixaxis controller), then the unknown axis get maps to ABS_MT_SLOT
> and
> > beyond.
> >
> > [1] https://lkml.org/lkml/2013/11/20/515
> > [2] 1384983141-31019-1-git-send-email-benjamin.tissoires at redhat.com
> >
> > [...]
>
> so, as I said above the libevdev behaviour is intentional and our
> indicator
> that this isn't a MT device after all. We should integrate that knowledge
> better so that we don't label a device as touch device when it isn't, and
> so
> that we process events from those axes as normal ABS events instead of MT
> events.

Unfortunately, my device (that Wireless Optical Desktop) doesn't produce
any events with the questionable codes, so if I would try to change
libinput behavior for these events to produce visible reaction, I'll not be
able to test changes for sanity.

I understand that my patch isn't general enough. It fixes my problem.
though, making mouse working in Weston. Current libinput code isn't
forgiving enough in handling of similar devices, so it cripples experience.
I'm not complaining, it's v0.5, so missing functionality is acceptable, but
it's frustrating.

I will file a bug report in hope that someone will propose more general fix=
.
As a sidenote, cited LKML message says that "the axis currently mapped on
ABS_MT_SLOT is a special case in the kernel,
and it is not updated", so I think processing axes as normal ABS events
will not work for the axis reported as ABS_MT_SLOT.

[Peter, sorry for spamming with this message in personal mail, it was my
unintentional mistake in using Gmail UI.]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140819/f17fc45e/attachment.html>