[lkml]   [2006]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: input: evdev.c EVIOCGRAB semantics question
    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"?

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-08-14 17:05    [W:0.048 / U:17.192 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site