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