* 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).