Re: input: evdev.c EVIOCGRAB semantics question

[Mattia Dongili]

Hello Dmitry,

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.

there's one more use case (don't know how much it's relevant but still
worth mentioning): pbbuttonsd v/s synaptics (x driver).

pbbuttonsd is a nice utility that (between the other things) monitors
keyboard and mouse activity and eventually sends the laptop to sleep.
The synaptics driver uses EVIOCGRAB and they don't work nice together
(eg: laptop goes to sleep even if actively using your touchpad)...

Now, with your proposal a user not using the synaptics driver and would
lose multiplexing to /dev/input/mice.

So why not just make EVIOCGRAB mean "don't send events to
mousedev but still report data to others opening the device"?

-- 
mattia
:wq!
-
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/