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

[Peter Hutterer]

On Tue, Aug 19, 2014 at 06:44:25PM +0300, Leonid Borisenko wrote:
> 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.

look at all the stuff in test/, it's fairly trivial to add your device (look
at litest-synaptics.c for example) and send events for any axis using
litest_event() or directly with libevdev_uinput_write_event().

plus, having a test makes sure we don't accidentally break things in the
future.

> 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=

You're pretty close with your fix already. In evdev_configure_device, check
for ABS_MT_SLOT and libevdev_get_num_slots() before setting device->is_mt.
If the number of slots is -1, don't set the mt flags and that's 80% of the
effort. so it's mostly just a bit of reshuffling.

> 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.

yeah, that's fine. but we should still handle all other axes correctly then.
at the very least, we should make sure that we don't crash if that happens.

Cheers,
   Peter