Le 11 mars 10 à 05:30, Peter Hutterer a écrit :
On Tue, Mar 09, 2010 at 11:42:34PM +0100, Mohamed Ikbel Boulabiar
wrote:
A hierarchy is imposing an unnecessary restriction on the graph
of possible
relations between point devices. Consider for instance the case
of two people,
each with one finger on the panel. The hierarchy says panel-
person1-finger1 and
panel-person2-finger1. Now have them move close enough for the
fingers to touch.
The hierarchy now says panel-person-(finger1, finger2). Symmetry
breaking once more.
The main point here is that however the data reaches userland, it
will have to
be processed intelligibly and collectively. The point of
processing could be an
MT X Driver, it could be some other input section, but it is has
to be done
somewhere.
Henrik
The hierarchy applied on multitouch isn't the best example to prove
benefits of it.
Hierarchy is useful with some complex input devices that have many
axes, many buttons some accelerometers, but that are hierarchical
from
the source (integrality/separability ?).
Then providing them as hierarchy can be useful.
Are we talking about real input devices here or a hypothetical device?
If the former, what are examples for such an input device?
A Wacom Cintiq is made of a touch panel, a bunch of buttons and two
sliders. Wait, there also are the thousands of pens that Wacom
shipped, each with a unique ID! If I own three of them, Wacom allows
my app to be interested only in the events from pen number 2. So, in
my mind, the Cintiq's touch panel is "made" of three pens. Two levels
of hierarchy.
OK, I admit that there is some multitouch in this example. Let's take
one without multitouch. I have an RFID reader and dozens of RFID tags
embedded in identification badges. Say my app is only interested in
badge #123 entering or leaving the proximity area of my reader. It's
useful to consider badge #123 as a device with two events (enter/
leave), subdevice of the RFID system.
The left button of my mouse is a button. Why am I not allowed to
focus on it as a device?
Today's application programmers have to bear with a definition of
"device" that is centered on the hardware USB architecture that some
electronic company has deemed optimal for their purposes. That
definition has very little to do with any kind of semantic
equivalence between device (same behaviour, same protocol), and even
less to do with any kind of usage pattern. This was bearable when
there were only mice, keyboards, and a few exotic devices; it will
become more and more of a problem with ubiquitous computing on the
horizon.
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
