* EVIOC mechanism for MT slots @ 2011-01-20 21:10 Rafi Rubin 2011-01-21 1:45 ` Ping Cheng 0 siblings, 1 reply; 6+ messages in thread From: Rafi Rubin @ 2011-01-20 21:10 UTC (permalink / raw) To: linux-input, Henrik Rydberg, Stephane Chatty, Dmitry Torokhov, Jiri Kosina <jkosi> Cc: Peter Hutterer, X.Org Devel List -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We've come across a little problem with filtered MT events. It seems there isn't a mechanism to request the full state. If a program opens a device there's no way it can see static objects. Consider for example a board game. If the user puts the pieces on a MT surface before starting the application, those pieces will not register and the state of the game will be incorrect. If there's opposition to this request, I suggest settling the dispute with a game of MT battleship :-) Rafi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNOKS3AAoJEPILXytRLnK2HssP/0HfUm6pcvI6DyRu5xUzVWWd THJ4lx9wytcxMkXucKugkai1l8lC60wUQeof1vE+T5TNWbQWPlA/dL+cmSGLCMkj 4JHXUg0p91I54oNwcRmkutxw+G9YOq45O4qHWaKUNVrxapaGnY74cnYlSDYo3Jec OALRdV+flJAmdZPNhAuQAdSTn30QE4TSbcmIveYYy9WEsC1416Qx1zXFkNlaRrf/ ytKe+oKg3tlVzcQ+sSjEMimRGoMmNnGv5EQ0ZdFVFIOphuqLWoWv6nE1ziiFiwWL bSoYN9vVjgBfUmhp+tOdxdKJMwARxoUiKsa/i2etyukJI5ULJ6s1I1oc3MQCw30m CUoe6jTkW9MPpMdZIN7ip2RNmCoCg5wQKZTlw/gx20ZTYBlaY0msdcf81O78/HuJ MqUqiCuI2ytnyKJQboOgfwmf6sau9BW4g36qkAdkITuunr653gCeHdTAMtETfAJ0 EVHyGC2jMI+X+rkBWL2I2Ax0r+Vvtvna/cuC+KrOBY0nIkr02ed3azeF0CJoblps wr844XGgHsnus9nscSERLBVW4y0RvUt2AhX5JUChF4xM8zDTItY4CojCyg50Crc+ J/3c/8QUBhSHgnDXxN4YEdxLlz3/xf/u2qaf/dVnY5P5sh6y6WoxjhHhI3M19yLq j26XxoED92WXFuz5Hv9s =GrDk -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: EVIOC mechanism for MT slots 2011-01-20 21:10 EVIOC mechanism for MT slots Rafi Rubin @ 2011-01-21 1:45 ` Ping Cheng 2011-01-21 3:57 ` Chris Bagwell 0 siblings, 1 reply; 6+ messages in thread From: Ping Cheng @ 2011-01-21 1:45 UTC (permalink / raw) To: Rafi Rubin, Dmitry Torokhov, Henrik Rydberg Cc: linux-input, Stephane Chatty, Jiri Kosina, Benjamin Tissoires, Peter Hutterer, X.Org Devel List Hi Dmitry, Rafi's request is a good use case for the "input: mt: Add EVIOC mechanism for MT slots" patchset that Henrik submitted last May. From the MT X driver experience we had in the last few months, retrieving all active contacts, especially in the case when different tool types are supported on the same logical port, is necessary to initialize the tools properly. Can you consider to merge the patchset into 2.6.38? Thank you. Ping -------- Original Message -------- Subject: Re: [PATCH 0/2] input: mt: Add EVIOC mechanism for MT slots Date: Thu, 27 May 2010 16:12:20 -0700 From: Dmitry Torokhov <dmitry.torokhov@gmail.com> To: Ping Cheng <pinglinux@gmail.com> CC: Henrik Rydberg <rydberg@euromail.se>, Andrew Morton <akpm@linux-foundation.org>, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, Mika Kuoppala <mika.kuoppala@nokia.com>, Peter Hutterer <peter.hutterer@who-t.net>, Benjamin Tissoires <tissoire@cena.fr>, Stephane Chatty <chatty@enac.fr>, Rafi Rubin <rafi@seas.upenn.edu>, Michael Poole <mdpoole@troilus.org> On Thursday, May 27, 2010 03:59:37 pm Ping Cheng wrote: On Thu, May 27, 2010 at 12:03 AM, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > 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@gmail.com> 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. tbh, I can not say that I will need it in my X driver for sure. But I vote for it to be merged. Well, at this point I am in "no users - no functionality" mode, so I will only count votes of users :P -- Dmitry On Thu, Jan 20, 2011 at 1:10 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > We've come across a little problem with filtered MT events. It seems there > isn't a mechanism to request the full state. If a program opens a device > there's no way it can see static objects. > > Consider for example a board game. If the user puts the pieces on a MT surface > before starting the application, those pieces will not register and the state of > the game will be incorrect. > > If there's opposition to this request, I suggest settling the dispute with a > game of MT battleship :-) > > Rafi -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: EVIOC mechanism for MT slots 2011-01-21 1:45 ` Ping Cheng @ 2011-01-21 3:57 ` Chris Bagwell 2011-01-21 7:58 ` Benjamin Tissoires 0 siblings, 1 reply; 6+ messages in thread From: Chris Bagwell @ 2011-01-21 3:57 UTC (permalink / raw) To: Ping Cheng Cc: Rafi Rubin, Dmitry Torokhov, Henrik Rydberg, linux-input, Stephane Chatty, Jiri Kosina, Benjamin Tissoires, Peter Hutterer, X.Org Devel List On Thu, Jan 20, 2011 at 7:45 PM, Ping Cheng <pinglinux@gmail.com> wrote: > Hi Dmitry, > > Rafi's request is a good use case for the "input: mt: Add EVIOC > mechanism for MT slots" patchset that Henrik submitted last May. From > the MT X driver experience we had in the last few months, retrieving > all active contacts, especially in the case when different tool types > are supported on the same logical port, is necessary to initialize the > tools properly. > > Can you consider to merge the patchset into 2.6.38? > > Thank you. > > Ping Agree. Although X/Y will change often, the tracking ID is stable. So during start up of applications it would be really useful to query pre-existing ABS_MT_TRACKING_ID so that user doesn't have to lift object/hand/whatever before application starts working. Chris > > -------- Original Message -------- > Subject: Re: [PATCH 0/2] input: mt: Add EVIOC mechanism for MT slots > Date: Thu, 27 May 2010 16:12:20 -0700 > From: Dmitry Torokhov <dmitry.torokhov@gmail.com> > To: Ping Cheng <pinglinux@gmail.com> > CC: Henrik Rydberg <rydberg@euromail.se>, Andrew Morton > <akpm@linux-foundation.org>, linux-input@vger.kernel.org, > linux-kernel@vger.kernel.org, Mika Kuoppala <mika.kuoppala@nokia.com>, > Peter Hutterer <peter.hutterer@who-t.net>, Benjamin Tissoires > <tissoire@cena.fr>, Stephane Chatty <chatty@enac.fr>, Rafi Rubin > <rafi@seas.upenn.edu>, Michael Poole <mdpoole@troilus.org> > > > On Thursday, May 27, 2010 03:59:37 pm Ping Cheng wrote: > > On Thu, May 27, 2010 at 12:03 AM, Dmitry Torokhov > > <dmitry.torokhov@gmail.com> wrote: > > 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@gmail.com> 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. > > tbh, I can not say that I will need it in my X driver for sure. But I > vote for it to be merged. > > > Well, at this point I am in "no users - no functionality" mode, so I will > only count votes of users :P > > -- > Dmitry > > On Thu, Jan 20, 2011 at 1:10 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> We've come across a little problem with filtered MT events. It seems there >> isn't a mechanism to request the full state. If a program opens a device >> there's no way it can see static objects. >> >> Consider for example a board game. If the user puts the pieces on a MT surface >> before starting the application, those pieces will not register and the state of >> the game will be incorrect. >> >> If there's opposition to this request, I suggest settling the dispute with a >> game of MT battleship :-) >> >> Rafi > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: EVIOC mechanism for MT slots 2011-01-21 3:57 ` Chris Bagwell @ 2011-01-21 7:58 ` Benjamin Tissoires 2011-01-21 9:15 ` Henrik Rydberg 0 siblings, 1 reply; 6+ messages in thread From: Benjamin Tissoires @ 2011-01-21 7:58 UTC (permalink / raw) To: Chris Bagwell Cc: Ping Cheng, Rafi Rubin, Dmitry Torokhov, Henrik Rydberg, linux-input, Stephane Chatty, Jiri Kosina, Benjamin Tissoires, Peter Hutterer, X.Org Devel List Hi, if the TrackingID is stable during the touch, the MT_SLOT is stable *between* the touches: if you put one finger on the surface, you get the slot 0. Then you release. Then you touch one finger again, and protocol B does not send the slot value. This is really problematic when launching applications that rely on evdev to work: you click with the mouse emulation on your icon to launch the program (one finger), and you start using your application with one finger only (opening of a file for instance) -> you are in an unstable case as the app does not know the slot state until you put another finger on the screen. So I'm in favor of applying this patch Henrik submitted last May. Cheers, Benjamin On Fri, Jan 21, 2011 at 04:57, Chris Bagwell <chris@cnpbagwell.com> wrote: > On Thu, Jan 20, 2011 at 7:45 PM, Ping Cheng <pinglinux@gmail.com> wrote: >> Hi Dmitry, >> >> Rafi's request is a good use case for the "input: mt: Add EVIOC >> mechanism for MT slots" patchset that Henrik submitted last May. From >> the MT X driver experience we had in the last few months, retrieving >> all active contacts, especially in the case when different tool types >> are supported on the same logical port, is necessary to initialize the >> tools properly. >> >> Can you consider to merge the patchset into 2.6.38? >> >> Thank you. >> >> Ping > > Agree. Although X/Y will change often, the tracking ID is stable. So > during start up of applications it would be really useful to query > pre-existing ABS_MT_TRACKING_ID so that user doesn't have to lift > object/hand/whatever before application starts working. > > Chris > >> >> -------- Original Message -------- >> Subject: Re: [PATCH 0/2] input: mt: Add EVIOC mechanism for MT slots >> Date: Thu, 27 May 2010 16:12:20 -0700 >> From: Dmitry Torokhov <dmitry.torokhov@gmail.com> >> To: Ping Cheng <pinglinux@gmail.com> >> CC: Henrik Rydberg <rydberg@euromail.se>, Andrew Morton >> <akpm@linux-foundation.org>, linux-input@vger.kernel.org, >> linux-kernel@vger.kernel.org, Mika Kuoppala <mika.kuoppala@nokia.com>, >> Peter Hutterer <peter.hutterer@who-t.net>, Benjamin Tissoires >> <tissoire@cena.fr>, Stephane Chatty <chatty@enac.fr>, Rafi Rubin >> <rafi@seas.upenn.edu>, Michael Poole <mdpoole@troilus.org> >> >> >> On Thursday, May 27, 2010 03:59:37 pm Ping Cheng wrote: >> >> On Thu, May 27, 2010 at 12:03 AM, Dmitry Torokhov >> >> <dmitry.torokhov@gmail.com> wrote: >> > 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@gmail.com> 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. >> >> tbh, I can not say that I will need it in my X driver for sure. But I >> vote for it to be merged. >> >> >> Well, at this point I am in "no users - no functionality" mode, so I will >> only count votes of users :P >> >> -- >> Dmitry >> >> On Thu, Jan 20, 2011 at 1:10 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> We've come across a little problem with filtered MT events. It seems there >>> isn't a mechanism to request the full state. If a program opens a device >>> there's no way it can see static objects. >>> >>> Consider for example a board game. If the user puts the pieces on a MT surface >>> before starting the application, those pieces will not register and the state of >>> the game will be incorrect. >>> >>> If there's opposition to this request, I suggest settling the dispute with a >>> game of MT battleship :-) >>> >>> Rafi >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-input" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: EVIOC mechanism for MT slots 2011-01-21 7:58 ` Benjamin Tissoires @ 2011-01-21 9:15 ` Henrik Rydberg 2011-01-21 9:22 ` Dmitry Torokhov 0 siblings, 1 reply; 6+ messages in thread From: Henrik Rydberg @ 2011-01-21 9:15 UTC (permalink / raw) To: Benjamin Tissoires Cc: Chris Bagwell, Ping Cheng, Rafi Rubin, Dmitry Torokhov, linux-input, Stephane Chatty, Jiri Kosina, Benjamin Tissoires, Peter Hutterer, X.Org Devel List > This is really problematic when launching applications that rely on > evdev to work: > you click with the mouse emulation on your icon to launch the program > (one finger), and you start using your application with one finger > only (opening of a file for instance) -> you are in an unstable case > as the app does not know the slot state until you put another finger > on the screen. > > So I'm in favor of applying this patch Henrik submitted last May. Great, so there seems to be sufficient interest to warrant revisiting this. If you can find the patches, I will queue them in my tree. ;-) And if Dmitry concurs, perhaps we can even aim at 2.6.38. Thanks, Henrik ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: EVIOC mechanism for MT slots 2011-01-21 9:15 ` Henrik Rydberg @ 2011-01-21 9:22 ` Dmitry Torokhov 0 siblings, 0 replies; 6+ messages in thread From: Dmitry Torokhov @ 2011-01-21 9:22 UTC (permalink / raw) To: Henrik Rydberg Cc: Benjamin Tissoires, Chris Bagwell, Ping Cheng, Rafi Rubin, linux-input, Stephane Chatty, Jiri Kosina, Benjamin Tissoires, Peter Hutterer, X.Org Devel List On Fri, Jan 21, 2011 at 10:15:19AM +0100, Henrik Rydberg wrote: > > This is really problematic when launching applications that rely on > > evdev to work: > > you click with the mouse emulation on your icon to launch the program > > (one finger), and you start using your application with one finger > > only (opening of a file for instance) -> you are in an unstable case > > as the app does not know the slot state until you put another finger > > on the screen. > > > > So I'm in favor of applying this patch Henrik submitted last May. > > Great, so there seems to be sufficient interest to warrant revisiting > this. If you can find the patches, I will queue them in my tree. ;-) > > And if Dmitry concurs, perhaps we can even aim at 2.6.38. > The reason I objected in the first place is that the patch was a "nice to have for completeness". Now that there are actual users needing this data I have no issues with adding ioctl to retrieve this data. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-01-21 9:22 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-01-20 21:10 EVIOC mechanism for MT slots Rafi Rubin 2011-01-21 1:45 ` Ping Cheng 2011-01-21 3:57 ` Chris Bagwell 2011-01-21 7:58 ` Benjamin Tissoires 2011-01-21 9:15 ` Henrik Rydberg 2011-01-21 9:22 ` Dmitry Torokhov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).