Le 27/05/2010 09:24, Dmitry Torokhov a écrit :
On Thu, May 27, 2010 at 09:08:10AM +0200, Benjamin Tissoires wrote:
Le 27/05/2010 09:03, Dmitry Torokhov a écrit :
On Wed, May 26, 2010 at 08:59:35AM -0700, Ping Cheng wrote:
On Tue, May 25, 2010 at 1:23 PM, Dmitry Torokhov
<dmitry.torokhov@xxxxxxxxx> wrote:
On Tue, May 25, 2010 at 09:52:29PM +0200, Henrik Rydberg wrote:
Dmitry Torokhov wrote:
Hi Henrik,
On Tue, May 25, 2010 at 01:52:57PM +0200, Henrik Rydberg wrote:
These patches are in response to the discussion about input state
retrieval.
The current EVIOCGABS method does not work with MT slots. These
patches provides a mechanism where a slot is first selected via a call
to EVIOCSABS, after which the corresponding MT events can be extracted
with calls to EVIOCGABS.
The symmetric operation, to set the MT state via EVIOCSABS, seems to
violate input data integrity, and is therefore not implemented.
This looks sane, however the question remains - is there any users for
this data? Like I mentioned, I can see the need to fetch state of
switches and ranges of absolute axis, and even non-multitouch ABS values
(due to the fact that some input devices, like sliders, may stay in a
certain position for long periods of time), but I expect multitouch data
to be "refreshed" very quickly.
Thanks.
There were some voices addressing this issue, and the patches are here,
available for whomever to pick up. Drop them if you wish, I will not send them anew.
I'll save them in my queue but will hold off applying until I hear
userspace folks requesting such functionality.
Hi Dmitry,
You do have a valid point - the (x,y) from a touch object would most
likely change all the time. Even if the object itself is in a steady
state on the digitizer, i.e., without any intentional movement, the
electronic noise would most likely lead to some (x,y) changes. So, the
chance that we need to retrieve (x,y) is rare.
However, it is possibe that when X driver starts, an object was
already on the digitizer. And the digitizer is of such a high quality
:), it filtered all the noises so we can not locate the touch without
a EVIOCGABS call.
Plus, from a pure coding/development point of view, it is not a bad
practice to provide the equivalent features for _MT_ support as we did
for the existing input devices. At least, it doesn't hurt to make the
support consistent across devices/tools (considering touch as a new
input device/tool).
Ping,
I did not say that there was a problem with the patch, I agree with it.
However if no one using this - why should we bother? Will _you_ utilize
this functionality in Wacom X driver? If so let me know and I will merge
it.
Hi Dmitry,
I'm the guy who submitted some patchs to enable multitouch in the
xf86-input-evdev driver. And I think that I will use the MT_SLOTS as
soon as they are available. It is much easier for the upper part to
have this protocol instead of the protocol type A.
This is not the question about slotted protocol (which is everyone
agrees is needed), the question is whether anyone will use EIVICGABS to
retrieve the initial MT values in case someone started touching the
device before X opened the corresponding /dev/input/eventX.
Sorry for the misunderstanding.
I can see at least 2 scenarios where such feature is interesting.
Scenario n°1:
Imagine a mt-enabled surface, like the Microsoft Surface or other big
devices. On these tables, we can put static objects that can be
recognized by a tag or just by their weight, size, etc. These objects
can be put before the X server starts and may be of interest. But since
these objects are "statics" the kernel driver does not send new values
and the X server does not see them, until they are moved by a human.
Here, I did not understood if the patch allows us to retrieve all slots
that are currently present on the surface or if we can have only the
last one.
Scenario n°2:
The Apple Magicmouse. This device is a mouse with a mt-surface on top of
it. If the filter is good enough, the device won't send the positions of
the fingers that are on the surface as we have quite a static position
while handling a mouse. In the case a user starts X and has a hand on
the mouse, the X server won't see them until they are actually moved.
This may not be a problem but if we need to know the mt-state while
sending the clicks, the driver can misunderstand the user aim.
But from what I understood, if the user has only one contact on the
surface, the slot will not be send and the X driver will be a little bit
lost concerning the slot in use.
So, I don't know if those patches will fit my needs, but for me, it is
clear that the X server will need to retrieve the state of the
mt-surface when the device is initialized.
I hope I'm not too far from the topic....
Cheers,
Benjamin
--
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
