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 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
-
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