input: mt: Document the MT event slot protocol (rev2)
in [Kernel]
|
Prev: [GIT PULL v2 0/5] perf tools fixes and improvements
Next: [RESEND -v2][PATCH 3/3] mem-hotplug: fix potential race while building zonelist for new populated zone
From: Peter Hutterer on 19 May 2010 20:20 On Wed, May 19, 2010 at 02:12:14PM +0200, Henrik Rydberg wrote: > Peter Hutterer wrote: > > On Tue, May 18, 2010 at 10:10:29PM +0200, Henrik Rydberg wrote: > >> This patch adds documentation for the SYN_MT_SLOT event and gives > >> examples of how to use the event slot protocol. > > > > thanks, this is really nice documentation! the approach seems good, though I > > do have a few questions inline. > > > [...] > > > > Is there a limit on the number of slots? > > The slots are dynamically allocated by the driver, so there is no practical > limit. Each slot currently takes 44 bytes, and allocating a few kilobytes of > kernel memory is not a problem. > > > Will all drivers with ABS_MT_TRACKING_ID use slots? if not, how can I know > > in advance if a device may use slots or not? > > Eventually, this might become true, but you are pointing at one of the weaker > points of the current setup. There is no bit field for the EV_SYN events, so > there is no way to know in advance if SYN_MT_SYNC or SYN_MT_SLOT is used. This > could quite possibly be added to the EVIO interface. Meanwhile, the method I use > is to detect the first SYN_MT_SLOT and select parser based on that information. I'd really prefer if there was some way to detect this. While I'm not quite sure how the matching X drivers would look like it's likely that the setups will be different for drivers that support slots and those that don't. e.g. those that don't have slots simply send events as valuators, those that do may split into multiple devices. Doing this at runtime - after the device has been set up is...tricky. > >> + > >> +Protocol Example B > >> +------------------ > >> + > >> +Here is what a minimal event sequence for a two-contact touch would look > >> +like for a type B device: > >> + > >> + SYN_MT_SLOT 0 > >> + ABS_MT_TRACKING_ID 45 > >> + ABS_MT_POSITION_X x[0] > >> + ABS_MT_POSITION_Y y[0] > >> + SYN_MT_SLOT 1 > >> + ABS_MT_TRACKING_ID 46 > >> + ABS_MT_POSITION_X x[1] > >> + ABS_MT_POSITION_Y y[1] > >> + SYN_REPORT > >> + > >> +Here is the sequence after moving contact 45 in the x direction: > >> + > >> + SYN_MT_SLOT 0 > >> + ABS_MT_POSITION_X x[0] > >> + SYN_REPORT > >> + > >> +Here is the sequence after lifting the contact in slot 0: > >> + > >> + ABS_MT_TRACKING_ID 0 > >> + SYN_REPORT > >> + > >> +The active slot is already 0, so the SYN_MT_SLOT is omitted. The message > >> +removes the association of slot 0 with contact 45, thereby destroying > >> +contact 45 and freeing slot 0 to be reused for another contact. > > > > I'm probably missing something here, but how would a process know which one > > is the active slot if it didn't get the previous event? > > I am assuming you are not talking about losing events in the stream, but simply > what information is available at the point of parsing it. The parser (the X > evdev driver for instance) keeps all attributes of all slots, plus a single > variable saying what slot is currently active, i.e, being modified. > > If you are thinking of a setup where one program is already hooked up to the > device, and a new one comes in just as the message in question appears on the > wire, it just means the new program will have to spend some time catching up. If > this should ever become a problem, one could possibly add a send-full-state > method to the input layer, to be issued when the new program opens the device. I > doubt this will be needed in practice though, since contacts change all the time. This was the case I was wondering about. While I agree with the last part (contacts change all the time) the side-effect that you'll get from this is that devices can seemingly be non-responsive for random periods of time. If you have a finger down when the X server starts or after a VT switch (or even a fast user switch), the driver will have to drop events. So you can wriggle your finger around and nothing happens, but once you lift it goes "well, now it works again". Since this happens only once in a while, it can make the whole lot appear flaky. Especially if one finger works and the other one doesn't. So I guess it comes down to whether sending SYN_MT_SLOT with every event costs too much compared to these admittedly rare use-cases. They're not much different to the current button events either, if you weren't there when a button was pressed you won't know. So I'm somewhat indifferent about this bit. And yes, you could add it once we find it's an issue, but by then someone has already spent time to work around this. And when you then start sending slot events all the time, you admit that writing the workaround was just a time waster :) > As a side note, the notion of a used slot depends on how the attributes of the > slot are interpreted. The method described in the document treats an > ABS_MT_TRACKING_ID value outside of the driver-specified value range as an > unused slot. It's easier for a latecomer to guess a tracking ID since you can just assign any random value to it, provided the kernel guarantees to only send updates on the tracking ID for changes. This doesn't quite work for slots. But I'm not sure what your last sentence means. Does this mean the kernel will open a new slot for out-of-range tracking IDs? I'm missing something here. Cheers, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Hutterer on 19 May 2010 20:30 On Wed, May 19, 2010 at 07:34:04PM -0400, Rafi Rubin wrote: > My understanding is that it would be more like > + SYN_MT_SLOT 0 > + ABS_MT_POSITION_X x > + ABS_MT_POSITION_Y y > + SYN_REPORT > + SYN_MT_SLOT 0 > + ABS_MT_POSITION_X x > + ABS_MT_POSITION_Y y > + SYN_REPORT > + SYN_MT_SLOT 0 > + ABS_MT_POSITION_X x > + ABS_MT_POSITION_Y y > + SYN_MT_SLOT 1 > + ABS_MT_POSITION_X x > + ABS_MT_POSITION_Y y > + SYN_REPORT > > > (2 events from 1 finger, followed by 1 event with both). where does the ABS_MT_BLOB_ID come in then? I thought this was the use-case it was added for. With the example above, you're updating the position for the finger three times, not specifying that there are 3 _simultaneous_ but disparate touches of the same finger. I'm thinking of a palm touch which may (for some hand shapes) gives you two blobs right next to each other but separated by a thin line. So palm + finger gives you three blobs in three slots, two of them linked by contact ID? Cheers, Peter > On 05/19/2010 06:43 PM, Ping Cheng wrote: > >Hi Henrik, > > > >I am trying to link the protocol to the actual multi-touch devices in > >my "mind". Hope it helps you to point out the mismatch between my > >imagination and the protocol. Please see details in line. > > > >Ping > > > >On Tue, May 18, 2010 at 1:10 PM, Henrik Rydberg<rydberg(a)euromail.se> wrote: > >>This patch adds documentation for the SYN_MT_SLOT event and > >>gives examples of how to use the event slot protocol. > > > >Am I right in thinking that SYN_MT_SLOT represents to the actual touch > >area/finger on the surface? There could be more than one (x,y) (a few > >points that form an irregular shape) that represents one finger. The > >following example shows that slot 0 (finger 1) touched three points on > >the surface while slot 1 (finger 2) only has one point reported: > > > >+ SYN_MT_SLOT 0 > >+ ABS_MT_TRACKING_ID 45 > >+ ABS_MT_POSITION_X x[0] > >+ ABS_MT_POSITION_Y y[0] > >+ ABS_MT_TRACKING_ID 46 > >+ ABS_MT_POSITION_X x[1] > >+ ABS_MT_POSITION_Y y[1] > >+ ABS_MT_TRACKING_ID 47 > >+ ABS_MT_POSITION_X x[2] > >+ ABS_MT_POSITION_Y y[2] > >+ SYN_MT_SLOT 1 > >+ ABS_MT_TRACKING_ID 30 > >+ ABS_MT_POSITION_X x[3] > >+ ABS_MT_POSITION_Y y[3] > >+ SYN_REPORT > > > >If my assumption is correct, i.e., one slot can have more than one > >point, I would think ABS_MT_TRACKING_ID may not have to be a required > >entry inside SYN_MT_SLOT. To the user land clients/drivers, > >SYN_MT_SLOT itself could serve as an ID. So, the following case is > >also a type B ( we know there are two touch areas. But we don't keep > >track of the points inside the areas): > > > >+ SYN_MT_SLOT 0 > >+ ABS_MT_POSITION_X x[0] > >+ ABS_MT_POSITION_Y y[0] > >+ ABS_MT_POSITION_X x[1] > >+ ABS_MT_POSITION_Y y[1] > >+ ABS_MT_POSITION_X x[2] > >+ ABS_MT_POSITION_Y y[2] > >+ SYN_MT_SLOT 1 > >+ ABS_MT_POSITION_X x[3] > >+ ABS_MT_POSITION_Y y[3] > >+ SYN_REPORT > > > >So, an EVIO for X driver to retrieve the number of SLOTs would be very > >helpful. Something like the following would do the work: > > > >input_set_abs_params(input_dev, ABS_MT_SLOT, 0, 12, 0, 0); > > > >which tells the user land clients that they can expect up to 13 touch areas. > > > >>+The main difference between the raw type A protocol and the higher level > >>+type B slot protocol lies in the usage of identifiable contacts. The slot > >>+protocol requires the use of the ABS_MT_TRACKING_ID, > > > >With what I said above, I think ABS_MT_TRACKING_ID is not the unique > >identifier for type B protocol. It is the fact that we can identify > >individual touch areas and use ABS_MT_SLOT to report them that makes > >it a type B event. > > > >>ABS_MT_TRACKING_ID, either provided by the > >>+hardware of computed from the raw data [5]. > > ^^ or (is it?) > > > >I agree with this ABS_MT_TRACKING_ID definition. I would think something like: > > > >input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, 47, 0, 0); > > > >which tells the clients that total of 48 points are tracked, would be helpful. > > > >Another topic that may be irrelevant to this patch is the filter. With > >the use of ABS_MT_TRACKING_ID, a filter can be applied to discard the > >useless repeated points or less than a certain number of points > >movement. > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafi Rubin on 19 May 2010 20:30 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/19/10 20:13, Ping Cheng wrote: > On Wed, May 19, 2010 at 4:34 PM, Rafi Rubin <rafi(a)seas.upenn.edu> wrote: >> My understanding is that it would be more like >> + SYN_MT_SLOT 0 >> + ABS_MT_POSITION_X x >> + ABS_MT_POSITION_Y y >> + SYN_REPORT >> + SYN_MT_SLOT 0 >> + ABS_MT_POSITION_X x >> + ABS_MT_POSITION_Y y >> + SYN_REPORT >> + SYN_MT_SLOT 0 >> + ABS_MT_POSITION_X x >> + ABS_MT_POSITION_Y y >> + SYN_MT_SLOT 1 >> + ABS_MT_POSITION_X x >> + ABS_MT_POSITION_Y y >> + SYN_REPORT > > You are right if one slot only has or is only allowed to have one > point. My scenario is that one slot can have more than one point. > Basically, my intention is to utilize the MT_SLOT and MT_TRACKING_ID > in such a way that it avoids as much overlap as possible. > > And hopefully it makes sesne in the reality too. Please clarify by what you mean by more than one point. I may be misunderstanding, but I thought that these slots are basically a superior replacement to tracking id. one finger -> one slot But with slots we can use the filtering that input provides, which we've been by-passing with the existing MT protocol (at least that's what I think Henrik's goal is). Rafi >> (2 events from 1 finger, followed by 1 event with both). >> >> >> On 05/19/2010 06:43 PM, Ping Cheng wrote: >>> >>> Hi Henrik, >>> >>> I am trying to link the protocol to the actual multi-touch devices in >>> my "mind". Hope it helps you to point out the mismatch between my >>> imagination and the protocol. Please see details in line. >>> >>> Ping >>> >>> On Tue, May 18, 2010 at 1:10 PM, Henrik Rydberg<rydberg(a)euromail.se> >>> wrote: >>>> >>>> This patch adds documentation for the SYN_MT_SLOT event and >>>> gives examples of how to use the event slot protocol. >>> >>> Am I right in thinking that SYN_MT_SLOT represents to the actual touch >>> area/finger on the surface? There could be more than one (x,y) (a few >>> points that form an irregular shape) that represents one finger. The >>> following example shows that slot 0 (finger 1) touched three points on >>> the surface while slot 1 (finger 2) only has one point reported: >>> >>> + SYN_MT_SLOT 0 >>> + ABS_MT_TRACKING_ID 45 >>> + ABS_MT_POSITION_X x[0] >>> + ABS_MT_POSITION_Y y[0] >>> + ABS_MT_TRACKING_ID 46 >>> + ABS_MT_POSITION_X x[1] >>> + ABS_MT_POSITION_Y y[1] >>> + ABS_MT_TRACKING_ID 47 >>> + ABS_MT_POSITION_X x[2] >>> + ABS_MT_POSITION_Y y[2] >>> + SYN_MT_SLOT 1 >>> + ABS_MT_TRACKING_ID 30 >>> + ABS_MT_POSITION_X x[3] >>> + ABS_MT_POSITION_Y y[3] >>> + SYN_REPORT >>> >>> If my assumption is correct, i.e., one slot can have more than one >>> point, I would think ABS_MT_TRACKING_ID may not have to be a required >>> entry inside SYN_MT_SLOT. To the user land clients/drivers, >>> SYN_MT_SLOT itself could serve as an ID. So, the following case is >>> also a type B ( we know there are two touch areas. But we don't keep >>> track of the points inside the areas): >>> >>> + SYN_MT_SLOT 0 >>> + ABS_MT_POSITION_X x[0] >>> + ABS_MT_POSITION_Y y[0] >>> + ABS_MT_POSITION_X x[1] >>> + ABS_MT_POSITION_Y y[1] >>> + ABS_MT_POSITION_X x[2] >>> + ABS_MT_POSITION_Y y[2] >>> + SYN_MT_SLOT 1 >>> + ABS_MT_POSITION_X x[3] >>> + ABS_MT_POSITION_Y y[3] >>> + SYN_REPORT >>> >>> So, an EVIO for X driver to retrieve the number of SLOTs would be very >>> helpful. Something like the following would do the work: >>> >>> input_set_abs_params(input_dev, ABS_MT_SLOT, 0, 12, 0, 0); >>> >>> which tells the user land clients that they can expect up to 13 touch >>> areas. >>> >>>> +The main difference between the raw type A protocol and the higher level >>>> +type B slot protocol lies in the usage of identifiable contacts. The >>>> slot >>>> +protocol requires the use of the ABS_MT_TRACKING_ID, >>> >>> With what I said above, I think ABS_MT_TRACKING_ID is not the unique >>> identifier for type B protocol. It is the fact that we can identify >>> individual touch areas and use ABS_MT_SLOT to report them that makes >>> it a type B event. >>> >>>> ABS_MT_TRACKING_ID, either provided by the >>>> +hardware of computed from the raw data [5]. >>> >>> ^^ or (is it?) >>> >>> I agree with this ABS_MT_TRACKING_ID definition. I would think something >>> like: >>> >>> input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, 47, 0, 0); >>> >>> which tells the clients that total of 48 points are tracked, would be >>> helpful. >>> >>> Another topic that may be irrelevant to this patch is the filter. With >>> the use of ABS_MT_TRACKING_ID, a filter can be applied to discard the >>> useless repeated points or less than a certain number of points >>> movement. >>> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv0gZgACgkQwuRiAT9o60/v5QCguYH/eGD4R12cIPGc/AF3Xz6Y RXgAoIfEYSVqekbLRU4NXHo0bnG323vA =OUmf -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafi Rubin on 19 May 2010 20:40 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/19/10 20:21, Peter Hutterer wrote: > On Wed, May 19, 2010 at 07:34:04PM -0400, Rafi Rubin wrote: >> My understanding is that it would be more like >> + SYN_MT_SLOT 0 >> + ABS_MT_POSITION_X x >> + ABS_MT_POSITION_Y y >> + SYN_REPORT >> + SYN_MT_SLOT 0 >> + ABS_MT_POSITION_X x >> + ABS_MT_POSITION_Y y >> + SYN_REPORT >> + SYN_MT_SLOT 0 >> + ABS_MT_POSITION_X x >> + ABS_MT_POSITION_Y y >> + SYN_MT_SLOT 1 >> + ABS_MT_POSITION_X x >> + ABS_MT_POSITION_Y y >> + SYN_REPORT >> >> >> (2 events from 1 finger, followed by 1 event with both). > > where does the ABS_MT_BLOB_ID come in then? I thought this was the use-case > it was added for. With the example above, you're updating the position for > the finger three times, not specifying that there are 3 _simultaneous_ but > disparate touches of the same finger. > > I'm thinking of a palm touch which may (for some hand shapes) gives you two > blobs right next to each other but separated by a thin line. > So palm + finger gives you three blobs in three slots, two of them linked by > contact ID? > > Cheers, > Peter Once again, I'm interpreting, perhaps with bias towards what I'd like it to mean. I think blobs are spatially localized contacts. It all the contacts which would most likely represent one hand. If you have two hands operating a screen (whether one or two people (hopefully not three)), you should have two blobs (I've been thinking about this concept in terms of "group" or "cluster") each with one of more contact. I think that gets interesting when you start thinking about larger scale environments where you will be using multiple hands, and multiple people. I think each blob should be allocated its own master pointer. And if you can bind a master keyboard to the blob too (perhaps an on screen keyboard), its trivial to imagine using that for a large table like surface where multiple people are using a single desktop independently. > >> On 05/19/2010 06:43 PM, Ping Cheng wrote: >>> Hi Henrik, >>> >>> I am trying to link the protocol to the actual multi-touch devices in >>> my "mind". Hope it helps you to point out the mismatch between my >>> imagination and the protocol. Please see details in line. >>> >>> Ping >>> >>> On Tue, May 18, 2010 at 1:10 PM, Henrik Rydberg<rydberg(a)euromail.se> wrote: >>>> This patch adds documentation for the SYN_MT_SLOT event and >>>> gives examples of how to use the event slot protocol. >>> >>> Am I right in thinking that SYN_MT_SLOT represents to the actual touch >>> area/finger on the surface? There could be more than one (x,y) (a few >>> points that form an irregular shape) that represents one finger. The >>> following example shows that slot 0 (finger 1) touched three points on >>> the surface while slot 1 (finger 2) only has one point reported: >>> >>> + SYN_MT_SLOT 0 >>> + ABS_MT_TRACKING_ID 45 >>> + ABS_MT_POSITION_X x[0] >>> + ABS_MT_POSITION_Y y[0] >>> + ABS_MT_TRACKING_ID 46 >>> + ABS_MT_POSITION_X x[1] >>> + ABS_MT_POSITION_Y y[1] >>> + ABS_MT_TRACKING_ID 47 >>> + ABS_MT_POSITION_X x[2] >>> + ABS_MT_POSITION_Y y[2] >>> + SYN_MT_SLOT 1 >>> + ABS_MT_TRACKING_ID 30 >>> + ABS_MT_POSITION_X x[3] >>> + ABS_MT_POSITION_Y y[3] >>> + SYN_REPORT >>> >>> If my assumption is correct, i.e., one slot can have more than one >>> point, I would think ABS_MT_TRACKING_ID may not have to be a required >>> entry inside SYN_MT_SLOT. To the user land clients/drivers, >>> SYN_MT_SLOT itself could serve as an ID. So, the following case is >>> also a type B ( we know there are two touch areas. But we don't keep >>> track of the points inside the areas): >>> >>> + SYN_MT_SLOT 0 >>> + ABS_MT_POSITION_X x[0] >>> + ABS_MT_POSITION_Y y[0] >>> + ABS_MT_POSITION_X x[1] >>> + ABS_MT_POSITION_Y y[1] >>> + ABS_MT_POSITION_X x[2] >>> + ABS_MT_POSITION_Y y[2] >>> + SYN_MT_SLOT 1 >>> + ABS_MT_POSITION_X x[3] >>> + ABS_MT_POSITION_Y y[3] >>> + SYN_REPORT >>> >>> So, an EVIO for X driver to retrieve the number of SLOTs would be very >>> helpful. Something like the following would do the work: >>> >>> input_set_abs_params(input_dev, ABS_MT_SLOT, 0, 12, 0, 0); >>> >>> which tells the user land clients that they can expect up to 13 touch areas. >>> >>>> +The main difference between the raw type A protocol and the higher level >>>> +type B slot protocol lies in the usage of identifiable contacts. The slot >>>> +protocol requires the use of the ABS_MT_TRACKING_ID, >>> >>> With what I said above, I think ABS_MT_TRACKING_ID is not the unique >>> identifier for type B protocol. It is the fact that we can identify >>> individual touch areas and use ABS_MT_SLOT to report them that makes >>> it a type B event. >>> >>>> ABS_MT_TRACKING_ID, either provided by the >>>> +hardware of computed from the raw data [5]. >>> ^^ or (is it?) >>> >>> I agree with this ABS_MT_TRACKING_ID definition. I would think something like: >>> >>> input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, 47, 0, 0); >>> >>> which tells the clients that total of 48 points are tracked, would be helpful. >>> >>> Another topic that may be irrelevant to this patch is the filter. With >>> the use of ABS_MT_TRACKING_ID, a filter can be applied to discard the >>> useless repeated points or less than a certain number of points >>> movement. >>> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv0g6UACgkQwuRiAT9o60927ACguoocWebY+/FxOvZ51Dx1WsAD sa0AoJjiLuuQG1/kcx8k/D1O4TeiTa1k =N7EH -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ping Cheng on 19 May 2010 21:00
On Wed, May 19, 2010 at 5:26 PM, Rafi Rubin <rafi(a)seas.upenn.edu> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/19/10 20:13, Ping Cheng wrote: >> On Wed, May 19, 2010 at 4:34 PM, Rafi Rubin <rafi(a)seas.upenn.edu> wrote: >>> My understanding is that it would be more like >>> + � SYN_MT_SLOT 0 >>> + � ABS_MT_POSITION_X x >>> + � ABS_MT_POSITION_Y y >>> + � SYN_REPORT >>> + � SYN_MT_SLOT 0 >>> + � ABS_MT_POSITION_X x >>> + � ABS_MT_POSITION_Y y >>> + � SYN_REPORT >>> + � SYN_MT_SLOT 0 >>> + � ABS_MT_POSITION_X x >>> + � ABS_MT_POSITION_Y y >>> + � SYN_MT_SLOT 1 >>> + � ABS_MT_POSITION_X x >>> + � ABS_MT_POSITION_Y y >>> + � SYN_REPORT >> >> You are right if one slot only has or is only allowed to have one >> point. My scenario is that one slot can have more than one point. >> Basically, my intention is to utilize the MT_SLOT and MT_TRACKING_ID >> in such a way that it avoids as much overlap as possible. >> >> And hopefully it makes sesne in the reality too. > > Please clarify by what you mean by more than one point. I might have been confused myself by ABS_MT_BLOB_ID and SYN_MT_SLOT here. What I meant by "more than one point" is a contact (or touch, I am not sure which one is the right term :) is represented by a few (x,y) coordinates. Maybe we should use SYN_MT_SLOT for my case? > I may be misunderstanding, but I thought that these slots are basically a > superior replacement to tracking id. > > one finger -> one slot This is what I needed to understand. Is slot for one (x,y) only or can it also be used for more than one set of (x,y)? > But with slots we can use the filtering that input provides, which we've been > by-passing with the existing MT protocol (at least that's what I think Henrik's > goal is). Good to know that filtering has already been considered. I know I must be out of sync with Henrik's goal. That's why I wanted to show my ignorance :). Ping -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |