LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] Input: Support for a less exclusive grab.
@ 2007-06-09  8:48 Zephaniah E. Hull
  2007-06-12  5:07 ` Dmitry Torokhov
  0 siblings, 1 reply; 22+ messages in thread
From: Zephaniah E. Hull @ 2007-06-09  8:48 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: linux-input, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]

EVIOCGRAB is nice and very useful, however over time I've gotten
multiple requests to make it possible for applications to get events
straight from the event device while xf86-input-evdev is getting events
from the same device.

Here is the least invasive patch I could think of, it changes the
behavior of EVIOCGRAB in some cases, specificly behavior is identical if
the argument is 0 or 1, however if the argument is true and != 1, then
it does a 'non exclusive grab', a better name might be handy.

What this does is allow the events to go to everything that's using
evdev to get events, but grabs it from anything else.  About as close to
what people want as I can get, and fairly non-invasive.

Signed-off-by: Zephaniah E. Hull <warp@aehallh.com>

---
 drivers/input/evdev.c |    6 +++++-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index be6b93c..385e856 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -29,6 +29,7 @@ struct evdev {
 	struct input_handle handle;
 	wait_queue_head_t wait;
 	struct evdev_client *grab;
+	int grab_exclusive;
 	struct list_head client_list;
 };
 
@@ -48,7 +49,7 @@ static void evdev_event(struct input_handle *handle, unsigned int type, unsigned
 	struct evdev *evdev = handle->private;
 	struct evdev_client *client;
 
-	if (evdev->grab) {
+	if (evdev->grab && evdev->grab_exclusive) {
 		client = evdev->grab;
 
 		do_gettimeofday(&client->buffer[client->head].time);
@@ -108,6 +109,7 @@ static int evdev_release(struct inode *inode, struct file *file)
 	if (evdev->grab == client) {
 		input_release_device(&evdev->handle);
 		evdev->grab = NULL;
+		evdev->grab_exclusive = 0;
 	}
 
 	evdev_fasync(-1, file, 0);
@@ -493,12 +495,14 @@ static long evdev_ioctl_handler(struct file *file, unsigned int cmd,
 				if (input_grab_device(&evdev->handle))
 					return -EBUSY;
 				evdev->grab = client;
+				evdev->grab_exclusive = ((long) p == 1);
 				return 0;
 			} else {
 				if (evdev->grab != client)
 					return -EINVAL;
 				input_release_device(&evdev->handle);
 				evdev->grab = NULL;
+				evdev->grab_exclusive = 0;
 				return 0;
 			}
 

-- 
	  1024D/E65A7801 Zephaniah E. Hull <warp@aehallh.com>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

It was then I realized how dire my medical situation was.  Here I was,
a network admin, unable to leave, and here was someone with a broken
network.  And they didn't ask me to fix it.  They didn't even try to
casually pry a hint out of me.
  -- Ryan Tucker in the SDM.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-06-09  8:48 [PATCH] Input: Support for a less exclusive grab Zephaniah E. Hull
@ 2007-06-12  5:07 ` Dmitry Torokhov
  2007-06-12  5:12   ` Zephaniah E. Hull
  0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Torokhov @ 2007-06-12  5:07 UTC (permalink / raw)
  To: Zephaniah E. Hull; +Cc: linux-input, linux-kernel

Hi Zephaniah,

On Saturday 09 June 2007 04:48, Zephaniah E. Hull wrote:
> EVIOCGRAB is nice and very useful, however over time I've gotten
> multiple requests to make it possible for applications to get events
> straight from the event device while xf86-input-evdev is getting events
> from the same device.
> 
> Here is the least invasive patch I could think of, it changes the
> behavior of EVIOCGRAB in some cases, specificly behavior is identical if
> the argument is 0 or 1, however if the argument is true and != 1, then
> it does a 'non exclusive grab', a better name might be handy.
> 
> What this does is allow the events to go to everything that's using
> evdev to get events, but grabs it from anything else.  About as close to
> what people want as I can get, and fairly non-invasive.

Unfortunately this also robs non-legacy input handlers (such as
rfkill-input) of input events. Does xf86-input-evdev really needs to
grab devices exclusively? I guess we can't abandon the standard
keyboard driver until X supports hotplugging. How close is it to
support devices coming and going?
 
If we can't remain as is until X hotplug is ready then I'd rather had
a separate ioctl that disables legacy input handlers (keyboard, mousedev)
for a given input device.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-06-12  5:07 ` Dmitry Torokhov
@ 2007-06-12  5:12   ` Zephaniah E. Hull
  2007-06-12  5:19     ` Dmitry Torokhov
  0 siblings, 1 reply; 22+ messages in thread
From: Zephaniah E. Hull @ 2007-06-12  5:12 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: linux-input, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

On Tue, Jun 12, 2007 at 01:07:13AM -0400, Dmitry Torokhov wrote:
> Hi Zephaniah,
> 
> On Saturday 09 June 2007 04:48, Zephaniah E. Hull wrote:
> > EVIOCGRAB is nice and very useful, however over time I've gotten
> > multiple requests to make it possible for applications to get events
> > straight from the event device while xf86-input-evdev is getting events
> > from the same device.
> > 
> > Here is the least invasive patch I could think of, it changes the
> > behavior of EVIOCGRAB in some cases, specificly behavior is identical if
> > the argument is 0 or 1, however if the argument is true and != 1, then
> > it does a 'non exclusive grab', a better name might be handy.
> > 
> > What this does is allow the events to go to everything that's using
> > evdev to get events, but grabs it from anything else.  About as close to
> > what people want as I can get, and fairly non-invasive.
> 
> Unfortunately this also robs non-legacy input handlers (such as
> rfkill-input) of input events. Does xf86-input-evdev really needs to
> grab devices exclusively? I guess we can't abandon the standard
> keyboard driver until X supports hotplugging. How close is it to
> support devices coming and going?

Er, to explain.

The current EVIOCGRAB does an exclusive grab that prohibits rfkill-input
and friends from working.

As it is the only way to disable the legacy input handlers,
xf86-input-evdev has been using it since we added it.

The patch is to let us cause only things that use /dev/input/event<n> to
get events, thus, a non-exclusive grab.

This basicly disables the legacy input handlers, and it's the least
invasive patch I could think of.

Going for a separate ioctl would also work, but in some ways it would
make supporting it more of a pain.

I don't care _that_ much either way, as long as we can get a way to
disable the legacy events while allowing other things to get the events
too.

Zephaniah E. Hull.
>  
> If we can't remain as is until X hotplug is ready then I'd rather had
> a separate ioctl that disables legacy input handlers (keyboard, mousedev)
> for a given input device.
> 
> -- 
> Dmitry
> 

-- 
	  1024D/E65A7801 Zephaniah E. Hull <warp@aehallh.com>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

Welcome to [telco] hell. [...] You are in a maze of twisty little PVC's,
all alike.  A switching engineer throws a dart at you!
    -- Chris Saunderson <saundo@idx.com.au> in the scary.devil.monastery

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-06-12  5:12   ` Zephaniah E. Hull
@ 2007-06-12  5:19     ` Dmitry Torokhov
  2007-06-12  5:23       ` Zephaniah E. Hull
  0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Torokhov @ 2007-06-12  5:19 UTC (permalink / raw)
  To: Zephaniah E. Hull; +Cc: linux-input, linux-kernel

On Tuesday 12 June 2007 01:12, Zephaniah E. Hull wrote:
> On Tue, Jun 12, 2007 at 01:07:13AM -0400, Dmitry Torokhov wrote:
> > Hi Zephaniah,
> > 
> > On Saturday 09 June 2007 04:48, Zephaniah E. Hull wrote:
> > > EVIOCGRAB is nice and very useful, however over time I've gotten
> > > multiple requests to make it possible for applications to get events
> > > straight from the event device while xf86-input-evdev is getting events
> > > from the same device.
> > > 
> > > Here is the least invasive patch I could think of, it changes the
> > > behavior of EVIOCGRAB in some cases, specificly behavior is identical if
> > > the argument is 0 or 1, however if the argument is true and != 1, then
> > > it does a 'non exclusive grab', a better name might be handy.
> > > 
> > > What this does is allow the events to go to everything that's using
> > > evdev to get events, but grabs it from anything else.  About as close to
> > > what people want as I can get, and fairly non-invasive.
> > 
> > Unfortunately this also robs non-legacy input handlers (such as
> > rfkill-input) of input events. Does xf86-input-evdev really needs to
> > grab devices exclusively? I guess we can't abandon the standard
> > keyboard driver until X supports hotplugging. How close is it to
> > support devices coming and going?
> 
> Er, to explain.
> 
> The current EVIOCGRAB does an exclusive grab that prohibits rfkill-input
> and friends from working.
> 

I understand that.

> As it is the only way to disable the legacy input handlers,
> xf86-input-evdev has been using it since we added it.
>

Like I said I would love if xf86-input-evdev did not grab the
device at all.
 
> The patch is to let us cause only things that use /dev/input/event<n> to
> get events, thus, a non-exclusive grab.
> 
> This basicly disables the legacy input handlers, and it's the least
> invasive patch I could think of.
> 

But rfkill-input is not a legacy handler. My objection is that with your
solution you still will rob handlers such rfkill-input of events.

> Going for a separate ioctl would also work, but in some ways it would
> make supporting it more of a pain.
> 
> I don't care _that_ much either way, as long as we can get a way to
> disable the legacy events while allowing other things to get the events
> too.
> 
> Zephaniah E. Hull.
> >  
> > If we can't remain as is until X hotplug is ready then I'd rather had
> > a separate ioctl that disables legacy input handlers (keyboard, mousedev)
> > for a given input device.
> > 
> > -- 
> > Dmitry
> > 
> 

-- 
Dmitry

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-06-12  5:19     ` Dmitry Torokhov
@ 2007-06-12  5:23       ` Zephaniah E. Hull
  2007-06-12  5:35         ` Dmitry Torokhov
  0 siblings, 1 reply; 22+ messages in thread
From: Zephaniah E. Hull @ 2007-06-12  5:23 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: linux-input, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 3606 bytes --]

*googles briefly for rfkill-input, looks for his brown paper bag*

On Tue, Jun 12, 2007 at 01:19:59AM -0400, Dmitry Torokhov wrote:
> On Tuesday 12 June 2007 01:12, Zephaniah E. Hull wrote:
> > On Tue, Jun 12, 2007 at 01:07:13AM -0400, Dmitry Torokhov wrote:
> > > Hi Zephaniah,
> > > 
> > > On Saturday 09 June 2007 04:48, Zephaniah E. Hull wrote:
> > > > EVIOCGRAB is nice and very useful, however over time I've gotten
> > > > multiple requests to make it possible for applications to get events
> > > > straight from the event device while xf86-input-evdev is getting events
> > > > from the same device.
> > > > 
> > > > Here is the least invasive patch I could think of, it changes the
> > > > behavior of EVIOCGRAB in some cases, specificly behavior is identical if
> > > > the argument is 0 or 1, however if the argument is true and != 1, then
> > > > it does a 'non exclusive grab', a better name might be handy.
> > > > 
> > > > What this does is allow the events to go to everything that's using
> > > > evdev to get events, but grabs it from anything else.  About as close to
> > > > what people want as I can get, and fairly non-invasive.
> > > 
> > > Unfortunately this also robs non-legacy input handlers (such as
> > > rfkill-input) of input events. Does xf86-input-evdev really needs to
> > > grab devices exclusively? I guess we can't abandon the standard
> > > keyboard driver until X supports hotplugging. How close is it to
> > > support devices coming and going?
> > 
> > Er, to explain.
> > 
> > The current EVIOCGRAB does an exclusive grab that prohibits rfkill-input
> > and friends from working.
> > 
> 
> I understand that.
> 
> > As it is the only way to disable the legacy input handlers,
> > xf86-input-evdev has been using it since we added it.
> >
> 
> Like I said I would love if xf86-input-evdev did not grab the
> device at all.

We have to disable the legacy input handlers somehow, not doing so
simply isn't an option.
>  
> > The patch is to let us cause only things that use /dev/input/event<n> to
> > get events, thus, a non-exclusive grab.
> > 
> > This basicly disables the legacy input handlers, and it's the least
> > invasive patch I could think of.
> > 
> 
> But rfkill-input is not a legacy handler. My objection is that with your
> solution you still will rob handlers such rfkill-input of events.

Urgh.

So, any thoughts on how to identify legacy input handlers in the input
system?

This is a tricky case I had not even been aware of.
> 
> > Going for a separate ioctl would also work, but in some ways it would
> > make supporting it more of a pain.
> > 
> > I don't care _that_ much either way, as long as we can get a way to
> > disable the legacy events while allowing other things to get the events
> > too.
> > 
> > Zephaniah E. Hull.
> > >  
> > > If we can't remain as is until X hotplug is ready then I'd rather had
> > > a separate ioctl that disables legacy input handlers (keyboard, mousedev)
> > > for a given input device.
> > > 
> > > -- 
> > > Dmitry
> > > 
> > 
> 
> -- 
> Dmitry
> 

-- 
	  1024D/E65A7801 Zephaniah E. Hull <warp@aehallh.com>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

>> kinds of numbers the tobacco industry wishes it had, and Dell is very
>> very happy with the results.
>
>Do they come with a Surgeon General warning on the box?

The new ones have "Designed for Windows XP". Yes.
  -- Satya, Paul Martin, and Derek Balling in the Scary Devil Monastery.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-06-12  5:23       ` Zephaniah E. Hull
@ 2007-06-12  5:35         ` Dmitry Torokhov
  2007-06-12  5:40           ` Zephaniah E. Hull
  0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Torokhov @ 2007-06-12  5:35 UTC (permalink / raw)
  To: Zephaniah E. Hull; +Cc: linux-input, linux-kernel

On Tuesday 12 June 2007 01:23, Zephaniah E. Hull wrote:
> On Tue, Jun 12, 2007 at 01:19:59AM -0400, Dmitry Torokhov wrote:
> > 
> > Like I said I would love if xf86-input-evdev did not grab the
> > device at all.
> 
> We have to disable the legacy input handlers somehow, not doing so
> simply isn't an option.

I do not follow. If user's xorg.conf does not use /dev/input/mice and
does not use "kbd" driver then grabbing is not required, is it? Now,
as far as I understand, lack of hotplug support in X is the main
obstacle for removing "mouse" and "kbd" drivers, correct?
 
> > 
> > But rfkill-input is not a legacy handler. My objection is that with your
> > solution you still will rob handlers such rfkill-input of events.
> 
> Urgh.
> 
> So, any thoughts on how to identify legacy input handlers in the input
> system?

I guess keyboard and mousedev will have to be flagged as such in kernel.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-06-12  5:35         ` Dmitry Torokhov
@ 2007-06-12  5:40           ` Zephaniah E. Hull
  2007-07-02 15:20             ` Vojtech Pavlik
  0 siblings, 1 reply; 22+ messages in thread
From: Zephaniah E. Hull @ 2007-06-12  5:40 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: linux-input, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]

On Tue, Jun 12, 2007 at 01:35:05AM -0400, Dmitry Torokhov wrote:
> On Tuesday 12 June 2007 01:23, Zephaniah E. Hull wrote:
> > On Tue, Jun 12, 2007 at 01:19:59AM -0400, Dmitry Torokhov wrote:
> > > 
> > > Like I said I would love if xf86-input-evdev did not grab the
> > > device at all.
> > 
> > We have to disable the legacy input handlers somehow, not doing so
> > simply isn't an option.
> 
> I do not follow. If user's xorg.conf does not use /dev/input/mice and
> does not use "kbd" driver then grabbing is not required, is it? Now,
> as far as I understand, lack of hotplug support in X is the main
> obstacle for removing "mouse" and "kbd" drivers, correct?

Sadly, not quite.

The problem is that if the user is not using the mouse and kbd drivers
at all, but is instead using xf86-input-evdev, and no grabbing is done,
then all key presses end up going to the console.

Consider the effects of this when using things like alt-f1 or ctrl-c in
a program in X.

We have to keep the console itself from getting the events in question,
which means either unbinding the kbd interface, or some other sort of
grab, otherwise xf86-input-evdev is completely unusable for keyboards.

Grab support was my initial approach to the problem, in hindsight it
wasn't the right one, but it worked, and it's still needed for the
multi-seat people.
>  
> > > 
> > > But rfkill-input is not a legacy handler. My objection is that with your
> > > solution you still will rob handlers such rfkill-input of events.
> > 
> > Urgh.
> > 
> > So, any thoughts on how to identify legacy input handlers in the input
> > system?
> 
> I guess keyboard and mousedev will have to be flagged as such in kernel.

Ugly, but it works.
> 
> -- 
> Dmitry
> 

-- 
	  1024D/E65A7801 Zephaniah E. Hull <warp@aehallh.com>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

"Microsoft is a cross between the Borg and the Ferengi.  Unfortunately,
they use Borg to do their marketing and Ferengi to do their
programming."
  -- Simon Slavin in asr

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-06-12  5:40           ` Zephaniah E. Hull
@ 2007-07-02 15:20             ` Vojtech Pavlik
  2007-07-03 16:45               ` Zephaniah E. Hull
  0 siblings, 1 reply; 22+ messages in thread
From: Vojtech Pavlik @ 2007-07-02 15:20 UTC (permalink / raw)
  To: Zephaniah E. Hull; +Cc: Dmitry Torokhov, linux-input, linux-kernel

On Tue, Jun 12, 2007 at 01:40:31AM -0400, Zephaniah E. Hull wrote:
> On Tue, Jun 12, 2007 at 01:35:05AM -0400, Dmitry Torokhov wrote:
> > On Tuesday 12 June 2007 01:23, Zephaniah E. Hull wrote:
> > > On Tue, Jun 12, 2007 at 01:19:59AM -0400, Dmitry Torokhov wrote:
> > > > 
> > > > Like I said I would love if xf86-input-evdev did not grab the
> > > > device at all.
> > > 
> > > We have to disable the legacy input handlers somehow, not doing so
> > > simply isn't an option.
> > 
> > I do not follow. If user's xorg.conf does not use /dev/input/mice and
> > does not use "kbd" driver then grabbing is not required, is it? Now,
> > as far as I understand, lack of hotplug support in X is the main
> > obstacle for removing "mouse" and "kbd" drivers, correct?
> 
> Sadly, not quite.
> 
> The problem is that if the user is not using the mouse and kbd drivers
> at all, but is instead using xf86-input-evdev, and no grabbing is done,
> then all key presses end up going to the console.

X still switches to its own VT, so those keys go to the X server via the
console, and GPM also knows about console switching ...

That is a sane way how to prevent the regular console from getting
keypresses/mouse movements.

-- 
Vojtech Pavlik
Director SuSE Labs

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-07-02 15:20             ` Vojtech Pavlik
@ 2007-07-03 16:45               ` Zephaniah E. Hull
  2007-07-03 22:15                 ` Vojtech Pavlik
  2007-09-29  3:05                 ` Ryan Lortie
  0 siblings, 2 replies; 22+ messages in thread
From: Zephaniah E. Hull @ 2007-07-03 16:45 UTC (permalink / raw)
  To: Vojtech Pavlik; +Cc: Dmitry Torokhov, linux-input, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]

On Mon, Jul 02, 2007 at 05:20:44PM +0200, Vojtech Pavlik wrote:
> On Tue, Jun 12, 2007 at 01:40:31AM -0400, Zephaniah E. Hull wrote:
> > On Tue, Jun 12, 2007 at 01:35:05AM -0400, Dmitry Torokhov wrote:
> > > On Tuesday 12 June 2007 01:23, Zephaniah E. Hull wrote:
> > > > On Tue, Jun 12, 2007 at 01:19:59AM -0400, Dmitry Torokhov wrote:
> > > > > 
> > > > > Like I said I would love if xf86-input-evdev did not grab the
> > > > > device at all.
> > > > 
> > > > We have to disable the legacy input handlers somehow, not doing so
> > > > simply isn't an option.
> > > 
> > > I do not follow. If user's xorg.conf does not use /dev/input/mice and
> > > does not use "kbd" driver then grabbing is not required, is it? Now,
> > > as far as I understand, lack of hotplug support in X is the main
> > > obstacle for removing "mouse" and "kbd" drivers, correct?
> > 
> > Sadly, not quite.
> > 
> > The problem is that if the user is not using the mouse and kbd drivers
> > at all, but is instead using xf86-input-evdev, and no grabbing is done,
> > then all key presses end up going to the console.
> 
> X still switches to its own VT, so those keys go to the X server via the
> console, and GPM also knows about console switching ...
> 
> That is a sane way how to prevent the regular console from getting
> keypresses/mouse movements.

Not really, what happens when the user presses alt-F1?  A way to tell
the kernel that events from a given input device should not go to the
console has been needed since the very first time an X driver allowed
keyboard events from /dev/input/event<n>, and that still has not
changed.

We just want a more flexible approach then what we are already using[0].

I'll see about writing something up when I get back to my computers[1]
and have things set back up[2].

Zephaniah E. Hull.

0: EVIOCGRAB.
1: The night of the 10th.
2: It could be a few days after I get back.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-07-03 16:45               ` Zephaniah E. Hull
@ 2007-07-03 22:15                 ` Vojtech Pavlik
  2007-09-29  3:05                 ` Ryan Lortie
  1 sibling, 0 replies; 22+ messages in thread
From: Vojtech Pavlik @ 2007-07-03 22:15 UTC (permalink / raw)
  To: Zephaniah E. Hull; +Cc: Dmitry Torokhov, linux-input, linux-kernel

On Tue, Jul 03, 2007 at 12:45:55PM -0400, Zephaniah E. Hull wrote:

> Not really, what happens when the user presses alt-F1?

Well, if the console is switched to medium raw or raw mode, nothing
happens.

> A way to tell the kernel that events from a given input device should
> not go to the console has been needed since the very first time an X
> driver allowed keyboard events from /dev/input/event<n>, and that
> still has not changed.

And the ages old method that X has been using before the existence of
the input layer still works fine, as far as I know.

> We just want a more flexible approach then what we are already using[0].

I'm fine with that, I just wonder whether attacking it on the input
layer side is the right way to do it: If you want to disable the
console, tell the console.

That way, we don't have to figure out which exact kernel input handlers
are console and which are not.

> I'll see about writing something up when I get back to my computers[1]
> and have things set back up[2].

Enjoy whatever computerless period you're planning!

-- 
Vojtech Pavlik
Director SuSE Labs

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-07-03 16:45               ` Zephaniah E. Hull
  2007-07-03 22:15                 ` Vojtech Pavlik
@ 2007-09-29  3:05                 ` Ryan Lortie
  2007-10-23 13:21                   ` Dmitry Torokhov
  1 sibling, 1 reply; 22+ messages in thread
From: Ryan Lortie @ 2007-09-29  3:05 UTC (permalink / raw)
  To: Zephaniah E. Hull; +Cc: linux-kernel, Vojtech Pavlik

On Tue, 2007-03-07 at 12:45 -0400, Zephaniah E. Hull wrote:
> We just want a more flexible approach then what we are already using[0].
> 
> I'll see about writing something up when I get back to my computers[1]
> and have things set back up[2].
> 
> Zephaniah E. Hull.
> 
> 0: EVIOCGRAB.
> 1: The night of the 10th.
> 2: It could be a few days after I get back.

Hello.

I have been working on a more flexible system for blocking the delivery
of input events to other agents in the system.

My approach is basically summed up as follows:

  - split the current purpose of input_handle into two parts

    - input_handle continues to exist as a mechanism for tracking which
      handlers are currently interested in a particular device

    - a new input_client now exists as a mechanism for tracking
      tracking who is interested in having events delivered from a
      particular device.

    As an example, for evdev, one input_handle will exist per event
    device in /dev/input and one input_client will exist per open().

  - cause input events to be delivered to 'clients' (ie: first argument
    is an input_client instead of input_handle)

  - add a concept of 'priority'

    - the new input_client structure has a priority field

    - the list of input_client's per device is kept sorted by this field

  - add the ability for the handler 'event' function to block further
    event propagation.  This is done by making the handler return 'int'
    instead of 'void'.  0: continue normally.  1: stop.

  - add "set priority" ioctl to evdev

  - add "set requested keys" ioctl to evdev.

    This causes delivery of only certain keycodes to this particular
    open().  I have no particular interest in doing this sort of masking
    for other (non-key) events but maybe it makes sense.

  - add "set filter" ioctl to evdev.

    This causes any "requested keys" to be consumed and not further
    delivered (ie: the event handler for this client will return 1).

  - also, as a small style issue: I made what I believe to be a
    simplification to the switch() statement in the evdev ioctl code.
    Whether this is actually a simplification or not is a matter of
    opinion. :)

  - port the non-evdev handlers (including rfkill) to the new
    handler/client interface in the most trivial way possible: open the
    input_client in the places where the old code used to call open with
    the input_handler.

The motivation is to allow arbitrary things in user-space to have a rich
support over blocking (possibly a select set of) key events from being
delivered to anything below a certain 'priority'.

I believe this will solve the problem of X wanting to block key delivery
to the VT module while still allowing the events to go through to rfkill
(which presumably will be given a higher priority).

This will also allow hal's "multimedia key" reporting code to be
improved in two ways: first, it can block the multimedia keys from being
delivered to X (and causing weird ^[[29~ things to appear in my
terminals) and second, it results in hal only waking up when an
"interesting key" is pressed (currently it wakes up on every single
keypress).

I have written a patch.  It is "over 40kb" so I don't include it
directly here.  It is available in its full form (or broken up) at this
url:

http://desrt.mcmaster.ca/code/input-patch/

This patch is not being proposed for inclusion in its current state.  In
addition to the many problems that I'm sure I don't even realise, here
are some that I would specifically like feedback on:

  - how should we decide what gets what priority level?

  - is it appropriate to have INPUT_PRIORITY_HIGH/LOW/SYSTEM/DEBUG, etc.
    macros in input.h?

  - why did the old code call flush() on the device before closing when
    disconnecting?  It seems particularly silly now that with my patch
    it will be called n times (one for each client)

  - how are switches supposed to be indented?  the "checkpatch" script
    in the kernel complained about my style despite following what was
    already in that file.

  - I haven't tested on big endian or "compat" systems at all.  As far
    as I know, the relevant code doesn't even compile.  Help here is
    appreciated (I don't have such a machine!).

  - there is small thread-safety issue with how I handle EVIOCSRKEYS on
    defined(CONFIG_COMPAT) && defined(__BIG_ENDIAN).  If events are
    delivered after the copy_from_user but before the word-swapping then
    events may be inappropriately dropped or delivered.  Do we care?

Ultimately, I'd very much like this to make it into 2.6.24 and I'm
willing to make the necessary changes to see that it happens.

Cheers


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-09-29  3:05                 ` Ryan Lortie
@ 2007-10-23 13:21                   ` Dmitry Torokhov
  2007-10-23 15:57                     ` Ryan Lortie
  0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Torokhov @ 2007-10-23 13:21 UTC (permalink / raw)
  To: Ryan Lortie; +Cc: Zephaniah E. Hull, linux-kernel, Vojtech Pavlik, linux-input

Hi Ryan,

On 9/28/07, Ryan Lortie <desrt@desrt.ca> wrote:
>
> Hello.
>
> I have been working on a more flexible system for blocking the delivery
> of input events to other agents in the system.
>
> My approach is basically summed up as follows:
>
>  - split the current purpose of input_handle into two parts
>
>    - input_handle continues to exist as a mechanism for tracking which
>      handlers are currently interested in a particular device
>
>    - a new input_client now exists as a mechanism for tracking
>      tracking who is interested in having events delivered from a
>      particular device.
>
>    As an example, for evdev, one input_handle will exist per event
>    device in /dev/input and one input_client will exist per open().
>
>  - cause input events to be delivered to 'clients' (ie: first argument
>    is an input_client instead of input_handle)
>
>  - add a concept of 'priority'
>
>    - the new input_client structure has a priority field
>
>    - the list of input_client's per device is kept sorted by this field
>
>  - add the ability for the handler 'event' function to block further
>    event propagation.  This is done by making the handler return 'int'
>    instead of 'void'.  0: continue normally.  1: stop.
>
>  - add "set priority" ioctl to evdev
>
>  - add "set requested keys" ioctl to evdev.
>
>    This causes delivery of only certain keycodes to this particular
>    open().  I have no particular interest in doing this sort of masking
>    for other (non-key) events but maybe it makes sense.
>
>  - add "set filter" ioctl to evdev.
>
>    This causes any "requested keys" to be consumed and not further
>    delivered (ie: the event handler for this client will return 1).
>
>  - also, as a small style issue: I made what I believe to be a
>    simplification to the switch() statement in the evdev ioctl code.
>    Whether this is actually a simplification or not is a matter of
>    opinion. :)
>
>  - port the non-evdev handlers (including rfkill) to the new
>    handler/client interface in the most trivial way possible: open the
>    input_client in the places where the old code used to call open with
>    the input_handler.
>
> The motivation is to allow arbitrary things in user-space to have a rich
> support over blocking (possibly a select set of) key events from being
> delivered to anything below a certain 'priority'.
>
> I believe this will solve the problem of X wanting to block key delivery
> to the VT module while still allowing the events to go through to rfkill
> (which presumably will be given a higher priority).
>
> This will also allow hal's "multimedia key" reporting code to be
> improved in two ways: first, it can block the multimedia keys from being
> delivered to X (and causing weird ^[[29~ things to appear in my
> terminals) and second, it results in hal only waking up when an
> "interesting key" is pressed (currently it wakes up on every single
> keypress).
>

I like the idea of limiting number of events that client wants to be
delivered to it. I think we need to extend it from keybit only to
event bitmask + keybit. This way, if keyboard has a scrollwheel or a
touchpad installed, HAL can still specify EV_KEY + KEY_XXX and ignore
all REL_* and ABS_* events.

Priority/filter idea is different matter. I don't think it is a giood
solution. There will always be an "arms race", new applications would
like to get in front of the queue all the time and it will be hard to
manage. X should just keep console open in raw mode and simply ignore
all events coming from it while using evdev driver. I understand that
X's hotplug support is getting there so you should be able to switch
to pure evdev setup pretty easy.

> I have written a patch.  It is "over 40kb" so I don't include it
> directly here.  It is available in its full form (or broken up) at this
> url:
>
> http://desrt.mcmaster.ca/code/input-patch/
>
> This patch is not being proposed for inclusion in its current state.  In
> addition to the many problems that I'm sure I don't even realise, here
> are some that I would specifically like feedback on:
>
>  - how should we decide what gets what priority level?
>

Exactly. You can't predict all future uses. There will always be
someone wanting to get in front of the line.

>  - is it appropriate to have INPUT_PRIORITY_HIGH/LOW/SYSTEM/DEBUG, etc.
>    macros in input.h?
>
>  - why did the old code call flush() on the device before closing when
>    disconnecting?  It seems particularly silly now that with my patch
>    it will be called n times (one for each client)

To remove any force-feedback effects installed by client that is being
disconnected.

>
>  - how are switches supposed to be indented?  the "checkpatch" script
>    in the kernel complained about my style despite following what was
>    already in that file.

I think I fixed this.

>
>  - I haven't tested on big endian or "compat" systems at all.  As far
>    as I know, the relevant code doesn't even compile.  Help here is
>    appreciated (I don't have such a machine!).
>
>  - there is small thread-safety issue with how I handle EVIOCSRKEYS on
>    defined(CONFIG_COMPAT) && defined(__BIG_ENDIAN).  If events are
>    delivered after the copy_from_user but before the word-swapping then
>    events may be inappropriately dropped or delivered.  Do we care?

Input core now has prper locking. You may take device's event_lock to
stop event propagation.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-10-23 13:21                   ` Dmitry Torokhov
@ 2007-10-23 15:57                     ` Ryan Lortie
  2007-10-23 18:10                       ` Dmitry Torokhov
  0 siblings, 1 reply; 22+ messages in thread
From: Ryan Lortie @ 2007-10-23 15:57 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: Zephaniah E. Hull, linux-kernel, Vojtech Pavlik, linux-input

On Tue, 2007-23-10 at 09:21 -0400, Dmitry Torokhov wrote:
> Priority/filter idea is different matter. I don't think it is a giood
> solution. There will always be an "arms race", new applications would
> like to get in front of the queue all the time and it will be hard to
> manage. X should just keep console open in raw mode and simply ignore
> all events coming from it while using evdev driver. I understand that
> X's hotplug support is getting there so you should be able to switch
> to pure evdev setup pretty easy.

The only reason that I don't like the numeric priority system is that I
believe it is arbitrary and a bit kludgy.  I don't think an arms race
will be a problem.  We don't have a lot of closed source applications
running as root on Linux and open source projects either choose sane
values or get patched (by users, distributions, etc) or don't get used.

I do believe there needs to be some concept of filtering events in such
a way that they reach some clients but not others -- that's half of the
purpose of this thread.  rfkill wants to be able to see keypresses while
they are kept away from X.  I'd be open to another way of handling this
but I think any other way will necessarily be more complex to use.

As for X using evdev, it still puts you in a position of two pieces of
software being required to know what events have been (conceptually)
"filtered" by various filters running on the system.  ie: the filter
itself needs to know, and also X needs to know so that it can remove
those key events from normal delivery.

So while I agree that the priority numbering is a bit kludgy (and have
no particular affinity to it) I do think that some prioritising system
is required and that pointing out the 'arms race' isn't a good reason to
write the whole idea off.  I'd gladly accept another method.

Note, of course, that the priorities mean nothing unless you actively
switch on filtering.

> >
> >  - how should we decide what gets what priority level?
> >
> 
> Exactly. You can't predict all future uses. There will always be
> someone wanting to get in front of the line.

Two proposals here:

1) Modules like rfkill could have parameters to set priority level.
Presumably, programs hooking in via evdev could also have their priority
configurable.  Leave it up to distributions (or users installing their
own software) to make sure everything is sane.

2) For matters like this, an unsigned int is a large place.  We could
easily use numbers like 10, 100, 1000 while still leaving plenty of room
between them and possibility for expansion on either side.

> Input core now has prper locking. You may take device's event_lock to
> stop event propagation.

noted.

Thanks for the review

Cheers


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-10-23 15:57                     ` Ryan Lortie
@ 2007-10-23 18:10                       ` Dmitry Torokhov
  2007-10-24  1:58                         ` Ryan Lortie
  0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Torokhov @ 2007-10-23 18:10 UTC (permalink / raw)
  To: Ryan Lortie; +Cc: Zephaniah E. Hull, linux-kernel, Vojtech Pavlik, linux-input

On 10/23/07, Ryan Lortie <desrt@desrt.ca> wrote:
> On Tue, 2007-23-10 at 09:21 -0400, Dmitry Torokhov wrote:
> > Priority/filter idea is different matter. I don't think it is a giood
> > solution. There will always be an "arms race", new applications would
> > like to get in front of the queue all the time and it will be hard to
> > manage. X should just keep console open in raw mode and simply ignore
> > all events coming from it while using evdev driver. I understand that
> > X's hotplug support is getting there so you should be able to switch
> > to pure evdev setup pretty easy.
>
> The only reason that I don't like the numeric priority system is that I
> believe it is arbitrary and a bit kludgy.  I don't think an arms race
> will be a problem.  We don't have a lot of closed source applications
> running as root on Linux and open source projects either choose sane
> values or get patched (by users, distributions, etc) or don't get used.
>
> I do believe there needs to be some concept of filtering events in such
> a way that they reach some clients but not others -- that's half of the
> purpose of this thread.  rfkill wants to be able to see keypresses while
> they are kept away from X.

No, rfkill want to see keypresses, period. It does not care if there
are other applications also seeing the same keypresses, it just does
not want keypresses stolen from it.

Rfkill should work just fine if there is a debug application capturing
events or a OSD utility monitoring RF state. Actually it would be
great if amy of the control utililities were split in 2 parts - one is
daemon running even without X and controlling RF starte, brightness,
suspend, etc, etc, and another part running in X (or some other
environment) providing OSD services. I mean it is really annoying when
you realize you can't suspend witha keypress because you happen to be
a KDM promot and not fully logged into a KDE session...

>  I'd be open to another way of handling this
> but I think any other way will necessarily be more complex to use.
>
> As for X using evdev, it still puts you in a position of two pieces of
> software being required to know what events have been (conceptually)
> "filtered" by various filters running on the system.  ie: the filter
> itself needs to know, and also X needs to know so that it can remove
> those key events from normal delivery.
>

Yes, applications need to decide whether they want to process certain
events or not. But I think that they shodul do it for themselves, not
for other applications. Otherwise dependencies are just insane and you
risk to disturb the peace just by adding another piece in the mix.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-10-23 18:10                       ` Dmitry Torokhov
@ 2007-10-24  1:58                         ` Ryan Lortie
  2007-10-24  3:33                           ` Dmitry Torokhov
  0 siblings, 1 reply; 22+ messages in thread
From: Ryan Lortie @ 2007-10-24  1:58 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: Zephaniah E. Hull, linux-kernel, Vojtech Pavlik, linux-input

On Tue, 2007-23-10 at 14:10 -0400, Dmitry Torokhov wrote:
> No, rfkill want to see keypresses, period. It does not care if there
> are other applications also seeing the same keypresses, it just does
> not want keypresses stolen from it.

Right.  This is exactly the problem.  The current grab API exists to
prevent keys from being delivered to normal users, but rfkill still
wants to see them.

No matter how you slice it, if both of these desires are to be satisfied
then there needs to be some sort of a system to differentiate between
rfkill and "normal users".  That's what the priority is here.

> Yes, applications need to decide whether they want to process certain
> events or not. But I think that they shodul do it for themselves, not
> for other applications. Otherwise dependencies are just insane and you
> risk to disturb the peace just by adding another piece in the mix.

I disagree.  Dependencies aren't a problem at all if people merely rely
on the kernel to take care of the appropriate filtering.  Dependencies
only become a problem when X needs to know about "ok... maybe I should
ignore keys that are handled by [hal] [rfkill] [others] etc...".

Cheers


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-10-24  1:58                         ` Ryan Lortie
@ 2007-10-24  3:33                           ` Dmitry Torokhov
  2007-10-24 15:35                             ` Zephaniah E. Hull
  0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Torokhov @ 2007-10-24  3:33 UTC (permalink / raw)
  To: Ryan Lortie; +Cc: Zephaniah E. Hull, linux-kernel, Vojtech Pavlik, linux-input

On Tuesday 23 October 2007, Ryan Lortie wrote:
> On Tue, 2007-23-10 at 14:10 -0400, Dmitry Torokhov wrote:
> > No, rfkill want to see keypresses, period. It does not care if there
> > are other applications also seeing the same keypresses, it just does
> > not want keypresses stolen from it.
> 
> Right.  This is exactly the problem.  The current grab API exists to
> prevent keys from being delivered to normal users, but rfkill still
> wants to see them.
> 
> No matter how you slice it, if both of these desires are to be satisfied
> then there needs to be some sort of a system to differentiate between
> rfkill and "normal users".  That's what the priority is here.
> 

And the solution is pretty simple - do not use grab.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-10-24  3:33                           ` Dmitry Torokhov
@ 2007-10-24 15:35                             ` Zephaniah E. Hull
  2007-10-25  5:37                               ` Ryan Lortie
  0 siblings, 1 reply; 22+ messages in thread
From: Zephaniah E. Hull @ 2007-10-24 15:35 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: Ryan Lortie, linux-kernel, Vojtech Pavlik, linux-input

On Tue, Oct 23, 2007 at 11:33:08PM -0400, Dmitry Torokhov wrote:
> On Tuesday 23 October 2007, Ryan Lortie wrote:
> > On Tue, 2007-23-10 at 14:10 -0400, Dmitry Torokhov wrote:
> > > No, rfkill want to see keypresses, period. It does not care if there
> > > are other applications also seeing the same keypresses, it just does
> > > not want keypresses stolen from it.
> > 
> > Right.  This is exactly the problem.  The current grab API exists to
> > prevent keys from being delivered to normal users, but rfkill still
> > wants to see them.
> > 
> > No matter how you slice it, if both of these desires are to be satisfied
> > then there needs to be some sort of a system to differentiate between
> > rfkill and "normal users".  That's what the priority is here.
> > 
> 
> And the solution is pretty simple - do not use grab.

xf86-input-evdev will never open the console in raw mode and toss the
data, it's not going to happen.

We need a way to, at the absolute minimum, unbind the keyboard from the
text console.  The current solution sucks for things like rfkill.

I'm not convinced that Ryan's fix is any better, but just saying that X
should open the console and ignore the characters is simply not an
option as far as I am concerned for X.

Zephaniah E. Hull.
> 
> -- 
> Dmitry
> 

-- 

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-10-24 15:35                             ` Zephaniah E. Hull
@ 2007-10-25  5:37                               ` Ryan Lortie
  2007-10-26 16:44                                 ` Zephaniah E. Hull
  0 siblings, 1 reply; 22+ messages in thread
From: Ryan Lortie @ 2007-10-25  5:37 UTC (permalink / raw)
  To: Zephaniah E. Hull
  Cc: Dmitry Torokhov, linux-kernel, Vojtech Pavlik, linux-input

On Wed, 2007-24-10 at 11:35 -0400, Zephaniah E. Hull wrote:
> We need a way to, at the absolute minimum, unbind the keyboard from the
> text console.  The current solution sucks for things like rfkill.
> 
> I'm not convinced that Ryan's fix is any better, but just saying that X
> should open the console and ignore the characters is simply not an
> option as far as I am concerned for X.

Can you think of any other way to separate things like rfkill/evdev from
things like the text console that's less hacky than my 'priority'
scheme?

Cheers



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-10-25  5:37                               ` Ryan Lortie
@ 2007-10-26 16:44                                 ` Zephaniah E. Hull
  2007-10-26 17:16                                   ` Ryan Lortie
  2007-10-26 17:29                                   ` Dmitry Torokhov
  0 siblings, 2 replies; 22+ messages in thread
From: Zephaniah E. Hull @ 2007-10-26 16:44 UTC (permalink / raw)
  To: Ryan Lortie; +Cc: Dmitry Torokhov, linux-kernel, Vojtech Pavlik, linux-input

On Thu, Oct 25, 2007 at 01:37:34AM -0400, Ryan Lortie wrote:
> On Wed, 2007-24-10 at 11:35 -0400, Zephaniah E. Hull wrote:
> > We need a way to, at the absolute minimum, unbind the keyboard from the
> > text console.  The current solution sucks for things like rfkill.
> > 
> > I'm not convinced that Ryan's fix is any better, but just saying that X
> > should open the console and ignore the characters is simply not an
> > option as far as I am concerned for X.
> 
> Can you think of any other way to separate things like rfkill/evdev from
> things like the text console that's less hacky than my 'priority'
> scheme?

What we really want to give is exclusitivity verses other 'end users',
as opposed the 'filters'.

I'm defining an 'end user' to be a handler that cares about all the
events from a device and plans on doing something with it.

That would be the console layer for keyboards, /dev/input/mice and
/dev/input/mouse<n> for mice, X for both of those, etc.

A 'filter' cares about a key or two, and might even want to remove it
from the stream, rfkill is a good example.

Now, how do we design for that?  Not a clue right now, still thinking
about it really.

Zephaniah E. Hull.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-10-26 16:44                                 ` Zephaniah E. Hull
@ 2007-10-26 17:16                                   ` Ryan Lortie
  2007-10-26 17:58                                     ` Zephaniah E. Hull
  2007-10-26 17:29                                   ` Dmitry Torokhov
  1 sibling, 1 reply; 22+ messages in thread
From: Ryan Lortie @ 2007-10-26 17:16 UTC (permalink / raw)
  To: Zephaniah E. Hull
  Cc: Dmitry Torokhov, linux-kernel, Vojtech Pavlik, linux-input

On Fri, 2007-26-10 at 12:44 -0400, Zephaniah E. Hull wrote:
> A 'filter' cares about a key or two, and might even want to remove it
> from the stream, rfkill is a good example.

The patch introduces two different features that work nicely together
but, by no means have to be used together.

1) set interested events

  By default, -all- events are delivered to an event device.  you only
  get selective delivery when you explicitly use the 'set bits' call.


2) filter

  Filter all events that have been delivered to the user from further
  propagation.


Notice that if you do not use feature #1 then you get all keystrokes
delivered to you (unless someone with a higher priority than you did
some filtering).  If you then use feature #2 then you filter everything
(since everything is delivered to you).



I really do think that this is good for your use case.  Your use of it
would basically involve opening the event device and saying
"ioctl(turn_filter_on);".  The default case is that all keys are
delivered (and therefore blocked from anyone below you).



Cheers


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-10-26 16:44                                 ` Zephaniah E. Hull
  2007-10-26 17:16                                   ` Ryan Lortie
@ 2007-10-26 17:29                                   ` Dmitry Torokhov
  1 sibling, 0 replies; 22+ messages in thread
From: Dmitry Torokhov @ 2007-10-26 17:29 UTC (permalink / raw)
  To: Ryan Lortie, Dmitry Torokhov, linux-kernel, Vojtech Pavlik, linux-input

On 10/26/07, Zephaniah E. Hull <warp@aehallh.com> wrote:
> On Thu, Oct 25, 2007 at 01:37:34AM -0400, Ryan Lortie wrote:
> > On Wed, 2007-24-10 at 11:35 -0400, Zephaniah E. Hull wrote:
> > > We need a way to, at the absolute minimum, unbind the keyboard from the
> > > text console.  The current solution sucks for things like rfkill.
> > >
> > > I'm not convinced that Ryan's fix is any better, but just saying that X
> > > should open the console and ignore the characters is simply not an
> > > option as far as I am concerned for X.
> >
> > Can you think of any other way to separate things like rfkill/evdev from
> > things like the text console that's less hacky than my 'priority'
> > scheme?
>
> What we really want to give is exclusitivity verses other 'end users',
> as opposed the 'filters'.
>
> I'm defining an 'end user' to be a handler that cares about all the
> events from a device and plans on doing something with it.
>
> That would be the console layer for keyboards, /dev/input/mice and
> /dev/input/mouse<n> for mice, X for both of those, etc.
>
> A 'filter' cares about a key or two, and might even want to remove it
> from the stream, rfkill is a good example.
>

No, rfkill does not want to remove anything from the event stream. It
perfectly happy with other users seeing the same events and doing
their own things with them.

> Now, how do we design for that?  Not a clue right now, still thinking
> about it really.
>

I really think that it should be solved by applications themselves.
Applications should only open devices they are interested in and only
process events they are interested in. The rest should be simply
ignored by the application. This is the only sane way. Otherwise we
will need to split applications into first and second class citizens
and have to manage dependencies between them.

The only exception is console because both kerenl and X are fighting
over control of VT switching. As a workaround one could open console
in raw mode. If this feels too "dirty" I guess we could have ioctl for
"taking over console" for applications willing to do so. The ioctl
would disable VT switching and touching LEDs by the console driver.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] Input: Support for a less exclusive grab.
  2007-10-26 17:16                                   ` Ryan Lortie
@ 2007-10-26 17:58                                     ` Zephaniah E. Hull
  0 siblings, 0 replies; 22+ messages in thread
From: Zephaniah E. Hull @ 2007-10-26 17:58 UTC (permalink / raw)
  To: Ryan Lortie; +Cc: Dmitry Torokhov, linux-kernel, Vojtech Pavlik, linux-input

On Fri, Oct 26, 2007 at 01:16:31PM -0400, Ryan Lortie wrote:
> On Fri, 2007-26-10 at 12:44 -0400, Zephaniah E. Hull wrote:
> > A 'filter' cares about a key or two, and might even want to remove it
> > from the stream, rfkill is a good example.
> 
> The patch introduces two different features that work nicely together
> but, by no means have to be used together.
> 
> 1) set interested events
> 
>   By default, -all- events are delivered to an event device.  you only
>   get selective delivery when you explicitly use the 'set bits' call.
> 
> 
> 2) filter
> 
>   Filter all events that have been delivered to the user from further
>   propagation.
> 
> 
> Notice that if you do not use feature #1 then you get all keystrokes
> delivered to you (unless someone with a higher priority than you did
> some filtering).  If you then use feature #2 then you filter everything
> (since everything is delivered to you).
> 
> 
> 
> I really do think that this is good for your use case.  Your use of it
> would basically involve opening the event device and saying
> "ioctl(turn_filter_on);".  The default case is that all keys are
> delivered (and therefore blocked from anyone below you).


But it's not really above/below, I don't want another X session with the
same priority level coming along and stealing the device, but I do want
to be able to steal it from the console.

I'm just not entirely convinced that we need priority levels, but if we
do go for them, then we want some documentation very clearly spelling
them out.
> 
> 
> 
> Cheers
> 

-- 

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2007-10-26 17:58 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-06-09  8:48 [PATCH] Input: Support for a less exclusive grab Zephaniah E. Hull
2007-06-12  5:07 ` Dmitry Torokhov
2007-06-12  5:12   ` Zephaniah E. Hull
2007-06-12  5:19     ` Dmitry Torokhov
2007-06-12  5:23       ` Zephaniah E. Hull
2007-06-12  5:35         ` Dmitry Torokhov
2007-06-12  5:40           ` Zephaniah E. Hull
2007-07-02 15:20             ` Vojtech Pavlik
2007-07-03 16:45               ` Zephaniah E. Hull
2007-07-03 22:15                 ` Vojtech Pavlik
2007-09-29  3:05                 ` Ryan Lortie
2007-10-23 13:21                   ` Dmitry Torokhov
2007-10-23 15:57                     ` Ryan Lortie
2007-10-23 18:10                       ` Dmitry Torokhov
2007-10-24  1:58                         ` Ryan Lortie
2007-10-24  3:33                           ` Dmitry Torokhov
2007-10-24 15:35                             ` Zephaniah E. Hull
2007-10-25  5:37                               ` Ryan Lortie
2007-10-26 16:44                                 ` Zephaniah E. Hull
2007-10-26 17:16                                   ` Ryan Lortie
2007-10-26 17:58                                     ` Zephaniah E. Hull
2007-10-26 17:29                                   ` 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).