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 <[email protected]>
---
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 <[email protected]>
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.
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
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 <[email protected]>
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 <[email protected]> in the scary.devil.monastery
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
*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 <[email protected]>
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.
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
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 <[email protected]>
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
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
Hi Ryan,
On 9/28/07, Ryan Lortie <[email protected]> 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
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
On 10/23/07, Ryan Lortie <[email protected]> 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
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
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
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
>
--
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
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.
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
On 10/26/07, Zephaniah E. Hull <[email protected]> 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
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
>
--