Re: input: evdev.c EVIOCGRAB semantics question

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

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

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/