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 18 May 2010 22:50 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. > Signed-off-by: Henrik Rydberg <rydberg(a)euromail.se> > --- > Documentation/input/multi-touch-protocol.txt | 201 ++++++++++++++++++-------- > 1 files changed, 137 insertions(+), 64 deletions(-) > > diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt > index c0fc1c7..100aec0 100644 > --- a/Documentation/input/multi-touch-protocol.txt > +++ b/Documentation/input/multi-touch-protocol.txt > @@ -6,31 +6,143 @@ Multi-touch (MT) Protocol > Introduction > ------------ > > -In order to utilize the full power of the new multi-touch devices, a way to > -report detailed finger data to user space is needed. This document > -describes the multi-touch (MT) protocol which allows kernel drivers to > -report details for an arbitrary number of fingers. > +In order to utilize the full power of the new multi-touch and multi-user > +devices, a way to report detailed data from multiple contacts, i.e., > +objects in direct contact with the device surface, is needed. This > +document describes the multi-touch (MT) protocol which allows kernel > +drivers to report details for an arbitrary number of contacts. > + > +The protocol is divided into two types, depending on the capabilities of the > +hardware. For devices handling anonymous contacts (type A), the protocol > +describes how to send the raw data for all contacts to the receiver. For > +devices capable of tracking identifiable contacts (type B), the protocol > +describes how to send updates for individual contacts via event slots. > + > + > +Protocol Usage > +-------------- > + > +Contact details are sent sequentially as separate packets of ABS_MT > +events. Only the ABS_MT events are recognized as part of a contact > +packet. Since these events are ignored by current single-touch (ST) > +applications, the MT protocol can be implemented on top of the ST protocol > +in an existing driver. > + > +Drivers for type A devices mark the end of a packet by calling the > +input_mt_sync() function, which generates a SYN_MT_REPORT event. This > +instructs the receiver to accept the data for the current contact and > +prepare to receive another. Drivers for type B devices mark the beginning > +of a packet by calling the input_mt_slot() function with a slot as > +argument, which generates a SYN_MT_SLOT event. This instructs the receiver > +to prepare for updates of the given slot. > + > +The end of a multi-touch transfer is marked by calling the usual > +input_sync() function. This instructs the receiver to act upon events > +accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new set > +of events/packets. > > +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, either provided by the > +hardware of computed from the raw data [5]. > > -Usage > ------ > +For type A devices, the kernel driver should generate an arbitrary > +enumeration of the set of anonymous contacts currently on the surface. The > +order in which the packets appear in the event stream is not important. > +Event filtering and finger tracking is left to user space [3]. > > -Anonymous finger details are sent sequentially as separate packets of ABS > -events. Only the ABS_MT events are recognized as part of a finger > -packet. The end of a packet is marked by calling the input_mt_sync() > -function, which generates a SYN_MT_REPORT event. This instructs the > -receiver to accept the data for the current finger and prepare to receive > -another. The end of a multi-touch transfer is marked by calling the usual > -input_sync() function. This instructs the receiver to act upon events > -accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new > -set of events/packets. > +For type B devices, the kernel driver should associate a slot with each > +identified contact, and use that slot to propagate changes for the contact. > +Creation, replacement and destruction of contacts is achieved by modifying > +the ABS_MT_TRACKING_ID of the associated slot. Since only changes are > +propagated, the full state of each initiated contact has to reside in the > +receiving end. Upon receiving an MT event, one simply updates the > +appropriate attribute of the active slot. Is there a limit on the number of slots? 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? [...] > + > +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? Cheers, Peter > + > +Finally, here is the sequence after lifting the second contact: > + > + SYN_MT_SLOT 1 > + ABS_MT_TRACKING_ID 0 > + SYN_REPORT > + > + > +Event Usage > +----------- > > A set of ABS_MT events with the desired properties is defined. The events > are divided into categories, to allow for partial implementation. The > minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which > -allows for multiple fingers to be tracked. If the device supports it, the > +allows for multiple contacts to be tracked. If the device supports it, the > ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size > -of the contact area and approaching finger, respectively. > +of the contact area and approaching contact, respectively. > > The TOUCH and WIDTH parameters have a geometrical interpretation; imagine > looking through a window at someone gently holding a finger against the > @@ -41,56 +153,26 @@ ABS_MT_TOUCH_MAJOR, the diameter of the outer region is > ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder > against the glass. The inner region will increase, and in general, the > ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than > -unity, is related to the finger pressure. For pressure-based devices, > +unity, is related to the contact pressure. For pressure-based devices, > ABS_MT_PRESSURE may be used to provide the pressure on the contact area > instead. > > -In addition to the MAJOR parameters, the oval shape of the finger can be > +In addition to the MAJOR parameters, the oval shape of the contact can be > described by adding the MINOR parameters, such that MAJOR and MINOR are the > major and minor axis of an ellipse. Finally, the orientation of the oval > shape can be describe with the ORIENTATION parameter. > > The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a > -finger or a pen or something else. Devices with more granular information > +contact or a pen or something else. Devices with more granular information > may specify general shapes as blobs, i.e., as a sequence of rectangular > shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices > that currently support it, the ABS_MT_TRACKING_ID event may be used to > -report finger tracking from hardware [5]. > - > -Here is what a minimal event sequence for a two-finger touch would look > -like: > +report contact tracking from hardware [5]. > > - ABS_MT_POSITION_X > - ABS_MT_POSITION_Y > - SYN_MT_REPORT > - ABS_MT_POSITION_X > - ABS_MT_POSITION_Y > - SYN_MT_REPORT > - SYN_REPORT > - > -Here is the sequence after lifting one of the fingers: > - > - ABS_MT_POSITION_X > - ABS_MT_POSITION_Y > - SYN_MT_REPORT > - SYN_REPORT > - > -And here is the sequence after lifting the remaining finger: > - > - SYN_MT_REPORT > - SYN_REPORT > - > -If the driver reports one of BTN_TOUCH or ABS_PRESSURE in addition to the > -ABS_MT events, the last SYN_MT_REPORT event may be omitted. Otherwise, the > -last SYN_REPORT will be dropped by the input core, resulting in no > -zero-finger event reaching userland. > > Event Semantics > --------------- > > -The word "contact" is used to describe a tool which is in direct contact > -with the surface. A finger, a pen or a rubber all classify as contacts. > - > ABS_MT_TOUCH_MAJOR > > The length of the major axis of the contact. The length should be given in > @@ -192,20 +274,11 @@ finger along the X axis (1). > Finger Tracking > --------------- > > -The kernel driver should generate an arbitrary enumeration of the set of > -anonymous contacts currently on the surface. The order in which the packets > -appear in the event stream is not important. > - > The process of finger tracking, i.e., to assign a unique trackingID to each > -initiated contact on the surface, is left to user space; preferably the > -multi-touch X driver [3]. In that driver, the trackingID stays the same and > -unique until the contact vanishes (when the finger leaves the surface). The > -problem of assigning a set of anonymous fingers to a set of identified > -fingers is a euclidian bipartite matching problem at each event update, and > -relies on a sufficiently rapid update rate. > - > -There are a few devices that support trackingID in hardware. User space can > -make use of these native identifiers to reduce bandwidth and cpu usage. > +initiated contact on the surface, is a Euclidian Bipartite Matching > +problem. At each event synchronization, the set of actual contacts are > +matched to the set of contacts from the previos synchronization. A full > +implementation can be found in [3]. > > > Gestures > -- > 1.6.3.3 > -- 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: Henrik Rydberg on 19 May 2010 08:20 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. >> + >> +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. 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. Cheers, Henrik -- 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 18:50 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 19:40 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). 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: Ping Cheng on 19 May 2010 20:20
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. > (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. >> > -- 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/ |