On 08/17/2010 09:49 AM, Stéphane Chatty wrote: > > Le 16 août 10 à 17:30, Henrik Rydberg a écrit : > >> Stéphane, Jiri, >> >> Regarding the several-hid-packets-per-actual-input-packet problem, >> what do you >> think about constructing a special MT HID device, using raw_event? It >> could >> encapsulate the current protocol a bit better and use the full HID >> extension. >> > > Hi Henrik > > This sounds like as a interesting direction for building a generic > driver for MT devices. However, there still are device specificities > that we need to deal with: > - the serial/parallel/hybrid issue, for which we have ideas but still > nothing firm; Not quite firm, but not too far from it either, IMO. Given that the hid-mt device and its drivers handle all input device interaction, the idea is to implement the details of the digitizer extension, such as hybrid mode, in the hid-mt device. > - some devices need to be set in multitouch mode; we need some research > to find out if this can be determined automatically from the report > descriptors; We could start off assuming all devices are different in this regard, and slowly work our way towards unification. > - the single touch emulation is highly device dependent. I was (and > still am) pretty proud of my choice of tracking the 'oldest' finger on > the panel: this turns multitouch panels into single touch panels that > are impervious to parasite touches. But the drawback is that currently > there is no generic method for this tracking: I used whatever > device-specific information I could use (order of fingers in a message, > tracking id, etc). Ah yes, the pointer emulation via ABS_X/Y. My personal view is that pointer emulation is a gesture, and thus best implemented in userspace. During multi-finger gestures, the pointer should either not move, or be hidden. The majority of kernel drivers emit a BTN_TOUCH==1 when the first finger lands on the surface, and a BTN_TOUCH==0 when the last finger leaves the surface. In userspace, for touchscreens, the BTN_TOUCH event is traditionally mapped to a button press, which is not what you want during a gesture. Thus, the pointer emulation logic has to be remapped in userspace, anyways. For new drivers, it would be best not to implement BTN_TOUCH/ABS_X/Y at all. Since most MT devices support legacy mouse mode out-of-the-box via HID, perhaps one can even argue that hid-mt does not _have_ to support ABS_X/Y. Or, to keep compatibility, we could provide emulation code in hid-mt. > As long as these issues are here, we still need a system for > implementing device-specific behaviour. I must admit I was tempted to > keep benefitting from the blacklist in hid-core.c until they are resolved. I agree. The implementation details I have in mind are to take the extra complexity involved using raw_event _once_, implement it in hid-mt, and then pass the digested events on to the specialized drivers. If done carefully, I imagine the changes to each individual driver to be fairly simple. > An additional question is: how do we decide that a device is a > multitouch one? Do we keep a list of devices? Or do we rely on a pattern > found in the report descriptors? In my view it would be great to have a > pattern matching system for identifying classes of input devices from > report descriptors, but then it would reacher farther than multitouch only. This sounds like an interesting idea for future development, but I would say we can continue to rely on the device list for now. Cheers, Henrik -- 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
