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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
