On 08/17/2010 09:49 AM, Stéphane Chatty wrote:

Le 16 août 10 à 17:30, Henrik Rydberg a écrit :

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html