Le 18/06/2010 08:53, Peter Hutterer a écrit :
On Fri, Jun 18, 2010 at 08:46:17AM +0200, Benjamin Tissoires wrote:
Le 18/06/2010 06:56, Peter Hutterer a ?crit :
On Fri, Jun 18, 2010 at 12:18:00AM -0400, Rafi Rubin wrote:
On Thu, Jun 17, 2010 at 11:51:34AM -0400, Chase Douglas wrote:
On Thu, 2010-06-17 at 12:16 +1000, Peter Hutterer wrote:
On Thu, Jun 10, 2010 at 05:47:57PM +0200, Benjamin Tissoires wrote:
Even if there is an interesting thread concerning the use of
multitouch on xorg-devel,
I still send the up-to-date patches to enable multitouch as valuators.
Changes since last time:
* Remove the detection of the maximum number of touches based on the
tracking ID
* changes in comments
Henrik, Rafi, others - any further comments on this? Patches look good
to
me, with a minor issue (see below) that can be fixed in a follow-up
patch.
From patch 2/3:
+#define ABS_MT_X_VALUE 0x8
+#define ABS_MT_Y_VALUE 0x16
It looks like ABS_MT_Y_VALUE should be 0x10.
:)
Peter, would you correct it ?
sure.
Overall this makes sense to me for devices where the MT data should be
attached to the cursor (i.e. like a magicmouse). How will this mesh with
direct input devices (or whatever mechanism is developed for multitouch
touchscreens)? It seems to me we will need to somehow tell the module
whether to pass the data as valuators or as DIDs, but not both. However,
that's an implementation detail that can be worked out later when we get
to it.
Benjamin - I'm not sure exposing the tracking ID in a valuator is a good
long-term solution. Does it provide any info that we do not already
have by
splitting the touchpoints into different valuators?
Why not expose the tracking ID? It's one less thing for the client to
worry about if it needs to track touches. Without the ID, clients would
have to implement their own tracking algorithms because they would just
get an array of touches. The same finger will be sent in a different
slot of the array on subsequent events, such as when a previous finger
is removed.
-- Chase
I believe the argument against is that the valuators already carry that
information implicitly (eg axis 12 would be Y of the third contact and
would continue in that role even if there are no
active contacts 1 and 2). As such having another valuator would be
wasteful.
yeah, it's superfluous and imo sending what is essentially an ID down an
axis
seems a bit odd at best. It's akin to sending a button number down as an
axis.
I agree with you, but only for the protocol that includes MT_SLOTS. As
the current patchwork deals with protocol A, and as this protocol
consists in a sort of pass-through (don't know if it's the word...) of
the device events, I think we should also send the trackingID.
When slots will be available, and the tracking will be done into the
kernel (or in mtdev), and Xinput2 masks will be available, we could just
drop the trackingID. But currently, for me, it's the only one solution
regards to the set of patches, as there is no tracking.
Let's have en example: the magicmouse. This devices sends the touches in
order from the lowest to the highest, even if the contact 2 is newer
than the contact 4. With this current implementation, and without the
trackingID, the client will see the contact 4 jumped to where is the new
contact 2, and creates a new one to the old position of contact 4.
why don't you work around this in the evdev driver then? that's the layer that
should honor the tracking ID and convert it into what's essentially slot
information.
If I start having states (to keep the link between trackingID and slots)
into the Xevdev driver, this will conflict with the handling of protocol
B (the one that will be available soon). That's my biggest and blocking
point.
I'd also request you have a look at adding the mask bits to the X server input
APIs. Afaict, this is the only reason we can't do this now and it is quite
fixable.
will do.
I don't want any client to rely on the tracking ID in the valuator
information, not even short term.
Ok, I think you could just apply the patch 1/3 named "Add the names of
the valuators for the multitouch properties". This patch is totally
separated of the input handling, but just adds the names.
We can wait a little for Henrik to publish mtdev and then just skip the
protocol A and directly apply protocol B (with slots and masks available).
Cheers,
Benjamin
On the other hand, some devices carry a tiny be of extra information
through the specific contact id's, and they are not strictly the lowest
set of numbers needed to express the contacts that
are active or have been activated since the last period of inactivity.
> From what I've heard the magic mouse (again) is one such example. I
haven't actually poked around enough to see it.
do you have any info on what this extra information could be?
See above ;) Also, the magicmouse retains the last position of each
contact and tries to reuse it when possible.
Cheers,
Benjamin
Personally I haven't yet come up with or heard an argument for caring
about the real tracking id values and every usage case I've come up with,
it would seem just as easily served computing it
>from in the client. However, I also know that I'm insufficiently
creative to eliminate the possibility that someone else would have a good
reason down the line. Would it make sense to leave
it as an option?
I'd like to see these patches accepted. Like Chase, I'm concerned how
this
will interact with the DID discussion. Would it make sense to apply it in
a
branch at very least so Ben doesn't have
to continualy maintain the changes while the discussion rolls on.
I expect it to provide some useful information once people start playing
with
it. It may not be the final approach but meanwhile, any info we can get on
how
we can handle input better is useful. Besides, the DID implementaion is
quite a
bit off, as far as I can tell.
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
