Re: input: evdev.c EVIOCGRAB semantics question

["Magnus Vigerlöf" <wigge@bigfoot.com>]

On Tuesday 15 August 2006 00:49, Magnus Vigerlöf wrote:
> On Monday 14 August 2006 17:15, Dmitry Torokhov wrote:
> [...]
>
> > > So why not just make EVIOCGRAB mean "don't send events to
> > > mousedev but still report data to others opening the device"?
> >
> > That darn layering thing. We don't want evdev to know about all other
> > handlers there are.
>
> Nonono... I think the layers is a good thingy, even in this case..
>
> What if you turn the whole thing around? Let the handler that should not
> get the events in case someone grabs the device (/dev/input/mice, more
> devices?) say it's so. And when the event is forwarded through the
> input-layer, check if the device is grabbed and in that case skip those
> handlers that shouldn't get any.
>
> It would require an additional field in the input_handle struct that should
> be set to non-zero for mousedev and a change in the event-propagation code
> to send events to all handlers except to those with a non-zero value if
> grabbed (I'd estimate it to be less than 5-10 lines that has to be
> added/changed).

And since /dev/input/mice does not have an own handler, but leeches the events 
from the handlers for /dev/input/mouse* this won't work as easily as I 
wrote.. Though if it get its own handler then it should be a simple thing... 
A few more lines of code that needs to be changed though, and the event loop 
will probably cost a little more to run.

> However, this doesn't address the problem I initially described (I
> think)... What if two application open the same device and one of the
> application do a EVIOCGRAB. Should both applications still get events? With
> the above fix two applications that opens /dev/input/mouse2 resp
> /dev/input/event4 for the same hw and the latter grabs the device, both
> will get events. Using a counter for grab (just like the open-counter) on
> the handler should make them behave the same way in both cases I think.
> Gnnn... I'll make a patch tomorrow (ok today, Tuesday) so you can see what
> I rambling about..
>
> Won't EVIOCGRAB be quite misnamed (not that I propose a change...) if we
> make a change like this though?
>
>  /Magnus
 /Magnus