Le 2 juin 10 à 17:51, Benjamin Tissoires a écrit :
There seems to be a misunderstanding here. The range of
ABS_MT_TRACKING_ID
should ideally be very large, much larger than the number of
supported fingers.
What you would want here is the maximum number of slots, according
to the type B
protocol. Until then, one should probably support as many fingers
as the
valuators can handle.
Well, I know that ABS_MT_TRACKING_ID shouldn't have anything to do
with the number of touchpoints the device can support. However,
currently, and for all devices that won't support protocol B (if
there are any), this is the only one parameter I know to retrieve
this max count. For instance, I thought some drivers of dual
touchscreen sends Tracking_id between 1 and 2 (hid-egalax I think).
But at least, if the max tracking id is 16, there is no point of
creating 24 touches for example.
I had in mind these dual touch devices in order not polluting their
valuators.
If you have any other suggestion (appart from slots, as this patch
does not handle them at all, and a later one will come when it will
be upstream), feel free to tell.
A solution would be to remove this test as dual touch devices could
easily use slots I think.
Most devices have low max values of ContactID, similar to the max
number of touches. But this is not a requirement, and Stantum panels
have IDs between 0 and 255 (used to be 0-65535 in old firmware
versions)... If, as is currently done, we direclty map ContactID onto
ABS_MT_TRACKING_ID, this could a problem couldn't it?
St.
_______________________________________________
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
