Re: [RFC] HID and multitouch

[Mohamed Ikbel Boulabiar <boulabiar@gmail.com>]

Hi,

For the first issue, it seems that the mapping should be put outside
the kernel itself.
Or in a more precise and possible solution, to create a small
component which will do the mapping.

For simple devices it can be done in textual mapping files, but for
others like multi-touch screens, a module doing dynamic mapping can be
a solution.

Rewriting the component to push it from static one2one mapping to
dynamic one may be a transparent solution for other components in next
layers.

Cheers,

Mohamed-Ikbel



On Sun, Dec 6, 2009 at 11:58 AM, Stéphane Chatty <chatty@enac.fr> wrote:
> Dear Jiri,
>
> over the last few months I have been working on HID quirks for a bunch of
> multitouch devices: NTrig, two flavours of Stantum devices, 3M, Acer T230H.
> For each of these I have working code, which I should be able to submit real
> soon now.
>
> However, people are asking me questions about why a specific driver is
> needed for each device. Answers are starting to emerge, and it looks like
> they might lead to some work on the Linux HID code itself:
>
> - the one-to-one mapping between HID and evdev is stretched to its limits
> with these devices that have several times the same group of HID fields in
> the same event: an event is made of fingers, each finger is made of an X, a
> Y and a few other fields. We need a mechanism to emit SYN_MT_REPORT between
> fingers.
>
> - furthermore, some fingers have to be discarded because they are
> placeholders with no valid data, and we know if to dump them only when they
> have been fully parsed. Therefore, we need a mechanism to cache finger data
> until the decision is made. Currently, the caching mechanism has to be
> device-dependent because the fields are not exactly the same and they come
> in a device-dependent order.
>
> - for all these devices, it is very tempting to have a touchscreen emulation
> so as to use them with existing software (X.org, particularly). Rafi and I
> share the idea that this should be done by creating two evdev nodes: a
> backward-compatible touchscreen, and a multitouch one. Most of the
> corresponding code could be shared among drivers. However, the algorithm for
> producing the touchscreen events differs from one device to another and we
> need to support this.
>
>
> Any opinions or suggestions?
>
> Cheers
>
> Stéphane
>
> --
> 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
>
--
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