Le 15 déc. 09 à 15:05, Jiri Kosina a écrit :
- 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?
OK. As soon as I have some time (january?) I'll have a look at this.
- 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?
Usually, we are speaking about x, y, w, h, id, pressure, each between
16 and 32 bits. If we want to perform single touch emulation (useful
for using the panels with current applications), some devices require
that we cache all fingers. In that case, multiply this by 6 to 10.
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?
Er, I guess yes. Less comfortable that the current device-specific
struct, but probably OK.
St.
--
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
