Le 9 mars 10 à 22:19, Jiri Kosina a écrit :
On Tue, 9 Mar 2010, Rafi Rubin wrote:
Since you're considering protocol clarification, what's your
opinion on
splitting the multi-touch and single touch (possibly emulated) to
separate input devices?
What would be the advantages?
One would be separation of concerns. If I'm interested in single
touch events, I'd be better off with no "multitouch noise". If I'm
interested in low level events, I'd be better off without the
interference created by all sorts of "clever" event emulation in
drivers. An easy way to do this is to have a different input node for
each protocol.
Dmitry has already replied to this that if protocols are independent
there is no problem with multiplexing them on the same node (I'm
rephrasing heavily, here). Still, with multiplexing things are a bit
less clear for programmers; this is not a clean object interface
protocol to say the least ;-) And sometimes there even are
interferences between protocols...
On another note, having multiple input nodes is a relevant question
when dealing with multitouch anyway. Let me take an example: consider
two users, each interacting with their own application in its own
window but on the same display. Now, consider these two input
possibilities: either each has their own mouse, or they both use the
same dual-touch panel. In the first case, each app can open its own
input node; in the second, they need to share the same device and
perform some filtering to extract the events they want (user1 or
user2). The symmetry breaking between the two situations is not
satisfactory: you need to change the code in the apps.
With this regard, I am a big fan of the idea of having hierarchical
devices, just like with have hierarchical file systems. Each finger
on the dual-touch panel would be a device, child of the panel device.
Each would be equivalent to a mouse, and voila, the symmetry is
restored. Conceptually, saying (panel/finger1, any event) or (panel,
finger1 events) are equivalent; but in the first case the routing is
done by the OS and in the second case it has to be done by the app,
which breaks reusability. There are other interesting perspectives,
but I don't want to get carried away too much.
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
