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 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.
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.
*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 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
Enabling/disabling input events.
The current trend is for events like power buttons and lid switches to be handled through the input subsystem. This leaves an odd hole for cases where you wish to set the hardware behavior of these buttons, specificly on the OLPC we have several events that signal through the input system, which are capable of waking the system from suspend mode. This is not always desirable, so the hardware leaves us a way to disable the button/switch completely, but at the moment there is no clean kernel interface for this. This leaves the choices of adding a separate way to control things which are delivered by the input system, which seems somewhat silly, or adding support to the input system for enabling/disabling specific events from an input device. The latter seems more useful in the long run, but it leaves the question of how to do it. Between a few of us, we see a few possible ways to do it off the top of our heads: - Adding controls somewhere off in /sys/class/input. (How do we handle notification of changes?) - Adding some ioctls to evdev. (Again, notification of changes?) - Writing events from userspace for these events, with odd values. (Ugly, easily confuses clients listening to those events who don't know what the odd values mean.) - Adding something like a EV_CTRL type, with CTRL_ENABLE_EVENT and CTRL_DISABLE_EVENT events, encoding the 16bit types and codes of the event we're enabling/disabling in the 32bit value. (How do we check the current value? Doesn't fit the existing event model.) All of these have ups and downs, and there are probably ways we have not thought of. So, our basic question is should this go through the input system, and if so how should we go about implementing it? Thank you. Zephaniah E. Hull. -- 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. Upholder Seen on the back of a T-Shirt: I am a bomb technician. If you see me running, try to keep up. signature.asc Description: Digital signature
Re: [PATCH] don't invert mightymouse hwheel
On Fri, Apr 13, 2007 at 08:40:18AM +0200, Johannes Berg wrote: On Thu, 2007-04-12 at 14:25 -0700, Barton C Massey wrote: I unfortunately don't have the hardware in question to test with. This X configuration is of course perfectly valid. I copied it straight out of the manpage so I'd hope so : Give me a day or so to check all this out. I don't think looking at the X behavior is too useful: too many place that the direction can be swapped. Instead, look which way the bits coming directly out of evdev point. I can do that (early next week), but I don't have any other devices to test with. Can provide a dump. IIRC I set things up so that positive X was the same as on other evdev devices. Is the supplied X config swapping the X axis with this line? Option evBits+1-2 No idea! I just copied it out of the manpage from evdev(4) As the xf86-input-evdev maintainer, I can tell you quite firmly that the answer is a solid no. However I can also tell you that I may infact have the behavior backwards in the driver. :) Yell, scream, and shout if that's the case. Zephaniah E. Hull. -- 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. If I have trouble installing Linux, something is wrong. Very wrong. -- Linus Torvalds on l-k. signature.asc Description: Digital signature
Re: [PATCH] don't invert mightymouse hwheel
Alright, note that at the moment there is no way to invert it except with xmodmap. (Since they get mapped as buttons, you can swap them there in a trivial fashion. If you're already swapping because you're left handed, it's even easier.) At the moment, we map positive hwheel to 6, and negative to 7. We also map positive wheel to 4, and negative to 5, so that fits. Once xf86-input-evdev is rewritten for the xserver input-hotplug, it will be a complete config file rewrite, but it will allow lots of really funky mapping that currently isn't supported. (It's 1.2.x, first with the old author was 1.0.x, 1.1.x broke everything but worked so much better it wasn't funny. 1.2.x with the right server hotplug code (which I'll write if I have to, urgh) should be a similar improvement.) Zephaniah E. Hull. On Wed, Apr 25, 2007 at 04:09:27PM -0700, Barton C Massey wrote: As far as I can tell you have it right, all the way up the stack for me. There's so many places it can get flipped, though, that it's hard to tell. Bart In message [EMAIL PROTECTED] you wrote: --bajzpZikUji1w+G9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 13, 2007 at 08:40:18AM +0200, Johannes Berg wrote: On Thu, 2007-04-12 at 14:25 -0700, Barton C Massey wrote: I unfortunately don't have the hardware in question to test with. This X configuration is of course perfectly valid. I copied it straight out of the manpage so I'd hope so : Give me a day or so to check all this out. I don't think looking at the X behavior is too useful: too many place that the direction can be swapped. Instead, look which way the bits coming directly out of evdev point. I can do that (early next week), but I don't have any other devices to test with. Can provide a dump. IIRC I set things up so that positive X was the same as on other evdev devices. Is the supplied X config swapping the X axis with this line? Option evBits+1-2 No idea! I just copied it out of the manpage from evdev(4) As the xf86-input-evdev maintainer, I can tell you quite firmly that the answer is a solid no. However I can also tell you that I may infact have the behavior backwards in the driver. :) Yell, scream, and shout if that's the case. Zephaniah E. Hull. -- 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. If I have trouble installing Linux, something is wrong. Very wrong. -- Linus Torvalds on l-k. --bajzpZikUji1w+G9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Digital signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGL7TaRFMAi+ZaeAERAvrAAJ9SbwKUwtHslgyE2aUESD1diHt4yQCg3p1i XqAtCSNKgyqhk2OzuppMbOQ= =F7/i -END PGP SIGNATURE- --bajzpZikUji1w+G9-- -- 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. }No. I just point out to troublemakers that I have an English degree, }which means that I am allowed to make changes to the English language. }(What _else_ could it possibly be for?) }Wow; in that case, my physics degree is *WAY* more useful than I }had thought. This just proves how useless a computer science degree is: there is hardly any useful science involved at all. I want my computer black magic degree! -- Victoria Swann, Jonathan Dursi, and D. Joseph Creighton on ASR signature.asc Description: Digital signature
