Re: input: evdev.c EVIOCGRAB semantics question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

On Sat, Aug 12, 2006 at 08:00:47PM -0400, Dmitry Torokhov wrote:
> On Saturday 12 August 2006 12:52, Zephaniah E. Hull wrote:
> > I can dust off the masking patch sometime here if Dmitry thinks that
> > he'd be willing to see a second method for this in addition to grabbing,
> > adding support to xf86-input-evdev would be trivial, and the same could
> > probably be said for the wacom driver that does grabbing at the moment.
> > 
> 
> I would not mind if we get it working right ;) Do we need to turn off
> "undesirable" handlers or do we want to limit output to one particular
> handler? I'd prefer the former, if possible. Do we keep a counter or
> set of counters so several processes can mask output, etc. Can we keep
> event delivery somewhat fast? 

EVIOCGRAB provides for the latter, though it seems to go too far and
mess with sysrq as well.

My old old EVIOCMASK patch just added a long (or was it an int?  It's
been a while) to each device struct, and to each handler struct, and if
they had bits set in common then they received the events, and if not
they did not.

That was the cost of a quick & operation and a branch in the input event
path, so not too expensive, though my memory seems to indicate that I
tried to play some evil games to invert the bits first to allow things
to be zero inited.

I'd definitely want to just rewrite it these days, but that approach is
fast, and if we define it something along the lines of 'bit 0 is the
kernel console layer, bit 1 is any further handlers in the kernel like
/dev/input/mice or the joystick interface, the rest belong to userspace'
that gives userspace plenty of bits for odd policy decisions.

One obvious catch is that programs would have to be careful to reset the
mask when leaving, though having the sysrq handler always present and
adding controls for 'reset input device masks' would be one escape
route for X masking keyboard events from the kernel, then crashing
messily.

We probably don't want to automaticly reset on close by a program that
did the masking, as I can see some cases where someone might want to use
a utility that adjusts the masks on input devices.


On a side note, if we mess with sysrq for the masking, we should add a
'ungrab all input devices' one as well.

Zephaniah E. Hull.

-- 
	  1024D/E65A7801 Zephaniah E. Hull <[email protected]>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

<aj> ``Who killed the server at the colo site?'' ``Weasel killed the
     server at the colo site'' ``Not me'' ``Then who?'' ``m2 killed the
     server at the colo site'' ...

Attachment: signature.asc
Description: Digital signature

[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]
  Powered by Linux