Re: input: evdev.c EVIOCGRAB semantics question

From: Dmitry Torokhov
Date: Mon Aug 14 2006 - 12:19:36 EST

On 8/14/06, Zephaniah E. Hull <warp@xxxxxxxxxxx> wrote:
On Mon, Aug 14, 2006 at 11:00:55AM -0400, Dmitry Torokhov wrote:
> On 8/14/06, Zephaniah E. Hull <warp@xxxxxxxxxxx> wrote:
> >On Mon, Aug 14, 2006 at 10:20:09AM -0400, Dmitry Torokhov wrote:
> >>
> >> I've been thinking about all of this and all of it is very fragile and
> >> unwieldy and I am not sure that we really need another ioctl after
> >> all. The only issue we have right now is that mousedev delivers
> >> undesirable events through /dev/input/mice while there is better
> >> driver listening to /dev/input/eventX and they clash with each other.
> >> Still, /dev/input/mice is nice for dealing with hotplugging of simple
> >> USB mice. So can't we make mousedev only multiplex devices that are
> >> not opened directly (where directly is one of mouseX, jsX, tsX, or
> >> evdevX)? We could even control this behavior through a module
> >> parameter. Then noone (normally) would need to use EVIOCGRAB.
> >
> >Sadly, the case of using EVIOCGRAB for mice to stop the use of
> >/dev/input/mice is actually not the primary usage.
> >
> >xf86-input-evdev will more or less happily continue talking to a mouse
> >that it can't grab, however things become somewhat more problematic when
> >it comes to keyboards.
> >
> >X needs to keep the keyboard driver from receiving events while it has
> >it open
> Keyboard... can't X just ignore data from old keyboard driver while
> evdev-based keyboard driver is used?

The problem is that without xf86-input-keyboard X ignores the keyboard
entirely, which means that the console driver gets it, so ctrl-C sends
signals, alt-F<n> switches consoles on you, etc.

Additional code to open the console, put the keyboard in raw mode, and
throw everything away would be problematic for a few reasons, one of
which being that people have managed, with grab, to keep X from being
attached to an actual console. (Used for multiple X sessions running at
once for instance.)

It also would mean that xf86-input-evdev would have to touch stuff that
otherwise it wouldn't have to come anywhere near.

I can see that. Unfortunately any form of "grabbing" just makes it all
worse in the long run. The problem is that some programs rely on X to
deliver events while others use device nodes (eventX, mouseX, or
super-new blahX) for their data. When X server grabs the devices it
interferes with other programs running on the same box making them
dependent on X configuration. I have the feeling that best course
would be for X to work out its own input handling and any
filtering/asking that is necessary.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at