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 ?
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.
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.
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
