Re: input: evdev.c EVIOCGRAB semantics question

["Zephaniah E. Hull" <warp@aehallh.com>]

On Sat, Aug 12, 2006 at 05:24:16PM +0200, Magnus Vigerlöf wrote:
> Hi,
> 
> What is the purpose of the EVIOCGRAB ioctl in evdev.c? Is it to prevent the 
> device driver from sending events to other event handlers? Is it to prevent 
> other applications from receiving events that has the device handler open? 
> First, last, or both?

As things stand, both.
> 
> I discovered the following behavior when I fired up a second X-server on my 
> machine with my Wacom tablet connected: The second X-server opened the tablet 
> as well and everything worked as it should. However when I switched back to 
> the first X-server the tablet didn't work at all. Only when I stopped the 
> second X-server did the tablet start working in the first X-server again. If 
> I changed the code in evdev to ignore the EVIOCGRAB-ioctl the tablet works in 
> both X-servers, but that caused other problems.

That is, unusual.  Unless each X server has it's own display, then when
switching VCs away from an X server the driver should be turned off, and
the device ungrabbed and possibly closed, at which point the other
should be able to open and grab the device.

The wacom X driver may not be handling that properly though, annoying.
> 
> Now, having two X-servers might not be the most common thing to have, but 
> having other applications that depends on the movement from the tablet might 
> be more common.
> 
> As is it now, it's useless (more or less) to run wacdump to display the tablet 
> specific events in a understandable manner. An application that generates 
> events through uinput based on tablet events and some other qualifiers 
> (mouseemu, simulating mouse scroll wheel) will not work either.

That one has been mentioned a few times, but rarely complained about
loudly.

When I drew up the first evdev grab patches I made a masking patch
shortly later which helped divide things, however that never made it
into code and that leaves us here.
> 
> And yes, the X-server must grab the tablet. Otherwise events will go 
> through /dev/input/mice as well and mess up applications that depend on the 
> tablet-specific absolute events.

This is close to the original reason for grabbing, specificly that there
was no safe way to use evdev for the keyboard at all without it.


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.

Regards.
Zephaniah E. Hull.
(Original author of the evdev grab patch and xf86-input-evdev
maintainer, among other things.)

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

>OK, fine. You're arguing semantics, though.

"arguing semantics" is not the same as "arguing nomenclature".  My DI
was very good at arguing semantics. He had this funny idea  that an
"unloaded" weapon was one that you had personally inspected  and that
the semantic difference mattered. Something about not  wanting to do
the paperwork of one of us killed someone with an  unloaded weapon.
Most technical debates are ultimately about semantics,  but that
doesn't mean that they are unimportant.
  -- Shmuel Metz and Steve Sobol on ASR.

Attachment: signature.asc
Description: Digital signature