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. Zephaniah E. Hull. -- 1024D/E65A7801 Zephaniah E. Hull <[email protected]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. I've always taken the position that if you can't find anything bad to say about a language or an operating system then you don't understand it. I also agree with you about the advocacy. AHS. ASS. -- Shmuel (Seymour J.) Metz in the Scary Devil Monastery.
Attachment:
signature.asc
Description: Digital signature
- Follow-Ups:
- Re: input: evdev.c EVIOCGRAB semantics question
- From: "Dmitry Torokhov" <[email protected]>
- Re: input: evdev.c EVIOCGRAB semantics question
- References:
- input: evdev.c EVIOCGRAB semantics question
- From: Magnus Vigerlöf <[email protected]>
- Re: input: evdev.c EVIOCGRAB semantics question
- From: "Zephaniah E. Hull" <[email protected]>
- Re: input: evdev.c EVIOCGRAB semantics question
- From: Dmitry Torokhov <[email protected]>
- Re: input: evdev.c EVIOCGRAB semantics question
- From: "Zephaniah E. Hull" <[email protected]>
- Re: input: evdev.c EVIOCGRAB semantics question
- From: "Dmitry Torokhov" <[email protected]>
- Re: input: evdev.c EVIOCGRAB semantics question
- From: "Zephaniah E. Hull" <[email protected]>
- Re: input: evdev.c EVIOCGRAB semantics question
- From: "Dmitry Torokhov" <[email protected]>
- input: evdev.c EVIOCGRAB semantics question
- Prev by Date: Re: Touchpad problems with latest kernels
- Next by Date: Mempool_alloc, bio_alloc_bioset deadlocks
- Previous by thread: Re: input: evdev.c EVIOCGRAB semantics question
- Next by thread: Re: input: evdev.c EVIOCGRAB semantics question
- Index(es):