Warning: evdev changes - no auto-grabs anymore

[Ville Syrjälä]

On Fri, Aug 15, 2008 at 10:10:10AM -0400, Dmitry Torokhov wrote:
> On Fri, Aug 15, 2008 at 11:26:29AM +0300, Ville Syrj?l? wrote:
> > On Fri, Aug 15, 2008 at 11:02:48AM +0300, Daniel Stone wrote:
> > > On Fri, Aug 15, 2008 at 09:51:59AM +0300, Ville Syrj?l? wrote:
> > > > On Fri, Aug 15, 2008 at 09:54:58AM +0930, Peter Hutterer wrote:
> > > > > On Thu, Aug 14, 2008 at 01:50:09PM -0400, Adam Jackson wrote:
> > > > > > This is, in fact, one of the main reasons I put SIOCGRAB there in the
> > > > > > first place; you need to keep the keyboard's event stream out of the tty
> > > > > > layer entirely, not just out of reach of the kbd driver.  At the time
> > > > > > the argument was also that you wanted to keep them out of reach of
> > > > > > normal users so you couldn't snoop passwords, but now that there's a
> > > > > > ConsoleKit I think that's less true.
> > > > > > 
> > > > > > Mac mouse emulation we could probably just blacklist away from the evdev
> > > > > > driver.  rfkill is... harder?  Does it get its own event device or not?
> > > > > > I'd think it would have to get one kill device per wireless device.
> > > > > 
> > > > > The issue is not grabbing the mouse emulation device, it's grabbing the
> > > > > keyboard that generates those keys events that should result in a button click
> > > > > on a different device. So we'd need something in the kernel I guess.
> > > > 
> > > > I was pondering about the same issue wrt. DirectFB. I wonder if
> > > > KDSETMODE/KD_GRAPHICS could be extended to take care of this or
> > > > would it break some existing applications.
> > > 
> > > Yeah, I was thinking about that, but that would mean we have issues
> > > under older kernels. I think the best was what I was proposing, which
> > > would be EVIOCSERIOUSLYDONTSENDANYCONSOLEINPUTWEWILLDEALWITHIT().
> > 
> > Yeah that would be better since support for it could be detected runtime
> > so the driver could do the right thing when running with a recent kernel,
> > and it could just fall back to the normal grab with old kernels.
> > 
> 
> If evdev support in X is maturing why does it even need using tty and
> mousedev multiplexors? If you just use evdev for all of your devices
> you would not have the problem of duplicate events coming from 2
> interfaces.

That's not the problem. The problem is that when using evdev without grabs
any keyboardish input also goes to the console. For stuff like ctrl-c it's
particularly nasty since it will result in the X server exiting.

This also affect DirectFB and it was the original reason why I added
EVIOCGRAB code to DirectFB's linux-input driver. Grabbing didn't cause
problems back then but now that the input subsystem is used by
rfkill/acpi/etc. functionalitys is lost when the devices are grabbed.

-- 
Ville Syrjälä
syrjala at sci.fi
http://www.sci.fi/~syrjala/