Re: input: evdev.c EVIOCGRAB semantics question

[Dmitry Torokhov]

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.

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/