Re: input: evdev.c EVIOCGRAB semantics question

["Dmitry Torokhov" <dmitry.torokhov@gmail.com>]

On 8/14/06, Zephaniah E. Hull <warp@aehallh.com> 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?

-- 
Dmitry