Benjamin Tissoires wrote: > > > 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 Thank you Benjamin, you got it all right. I thought something similar to what you describe when writing the patches. I agree with Dmitry that in general, an MT contact state is dynamic enough not to need much state initialization, but I also agree with you that there are cases where it is indeed needed. Henrik -- 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
