Re: input: evdev.c EVIOCGRAB semantics question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/14/06, Zephaniah E. Hull <[email protected]> wrote:
On Mon, Aug 14, 2006 at 11:00:55AM -0400, Dmitry Torokhov wrote:
> On 8/14/06, Zephaniah E. Hull <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux