On Fri, 13 Aug 2010, Stéphane Chatty wrote: > In summary this is a new kind of panel with an unusual HID prototol and the > hid-egalax driver fails at producing a proper event sequence. The major issue > here is that the key to resolving the problem does *not* lie in the driver: > SYNC messages are produced in hid-input.c and drivers cannot block them. To > address this, one would need to make the <HID event> -> <input event> + <sync> > mapping less systematic. This could converge with the efforts required if we > were to have a more generic management of multitouch devices (we need one > driver for each device because hid-core.c was not designed with this kind of > device in mind). > > My suggestions: > - accept the patch, after adding a few comments in the code about this device > requiring future care for its 'serial' protocol. > - start thinking about what changes are required in hid-input and/or hid-core > for a more generic management of multitouch devices. Hi Stephane, thanks for the analysis. How do devices in their report descriptor describe the fact whether the events should be interleaved by sync or not? We definitely could create a specialized version of hidinput_report_event() for certain reports, which wouldn't issue the input_sync() call, but I wonder what is the distinguishing factor. -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
