<div dir="ltr">2014-08-19 10:02 GMT+03:00 Peter Hutterer <<a href="mailto:peter.hutterer@who-t.net">peter.hutterer@who-t.net</a>>: > 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] <a href="https://lkml.org/lkml/2013/11/20/515">https://lkml.org/lkml/2013/11/20/515</a> > > [2] <a href="mailto:1384983141-31019-1-git-send-email-benjamin.tissoires@redhat.com">1384983141-31019-1-git-send-email-benjamin.tissoires@redhat.com</a> > > > > [...] > > 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. <div> </div><div>Unfortunately, my device (that Wireless Optical Desktop) doesn't produce </div>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.<div> </div><div>[Peter, sorry for spamming with this message in personal mail, it was my</div> <div>unintentional mistake in using Gmail UI.] </div></div>