Re: [PATCH] hid-ntrig.c Multitouch cleanup and fix

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Tue, Mar 09, 2010 at 11:03:07PM +0100, Stéphane Chatty wrote:
> 
> 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...

One of the main problems with splitting data into several input devices
is that it is still the same physical device, but now is potentially
handled by 2 separate drivers (unless we manage to fold entire
userspaceinto a single driver which I doubt its a good idea - I think
synaptics/evdev split worked well for non-multitouch devices) causing
double events to be reported to userspace. It is /dev/input/mice all
over again.

> 
> 
> 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.

Theoretically it is nice but it practice the cases are differemt: with
mice you are dealing with 2 separate devices whereas with touchscreen
there is one and it is mater of interpretation whether 2 touches should
be taken as independent events or a complex gestures.


-- 
Dmitry
--
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