On Sun, 6 Dec 2009, Stéphane Chatty wrote: > 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. Hi Stéphane, that's an excellent news, thanks! > 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. This should be rather striaghtforward, right? I don't see any principal issue here. If you provide such patch, I will happuly merge it. Introducing wrapper around hidinput_hid_event() which drivers for multitouch devices will be using should be sufficient, shouldn't it? > - 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. What kind of caching is required here? Is there any upper bound approximation on the amount of data that need to be cached? Would simple infrastructure, introducing linked list of [usage, value] tuples, together with "flush()" method, that will again only call hidinput_hid_event multiple times, be enough to be common for all drivers needing this? Thanks, -- 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
