Re: [PATCH] Input: Support for a less exclusive grab.
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/mousen 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.
Re: [PATCH] Input: Support for a less exclusive grab.
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/mousen 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
Re: [PATCH] Input: Support for a less exclusive grab.
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 --
Re: [PATCH] Input: Support for a less exclusive grab.
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 --
Re: [PATCH] Input: Support for a less exclusive grab.
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
Re: [PATCH] Input: Support for a less exclusive grab.
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
Re: [PATCH] Input: Support for a less exclusive grab.
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
Re: [PATCH] Input: Support for a less exclusive grab.
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/eventn 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 signature.asc Description: Digital signature
Re: [PATCH] Input: Support for a less exclusive grab.
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/eventn 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
Re: [PATCH] Input: Support for a less exclusive grab.
*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/eventn 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. signature.asc Description: Digital signature
Re: [PATCH] Input: Support for a less exclusive grab.
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
Re: [PATCH] Input: Support for a less exclusive grab.
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 signature.asc Description: Digital signature
[PATCH] Input: Support for a less exclusive grab.
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.
signature.asc
Description: Digital signature
