Warning: evdev changes - no auto-grabs anymore

[Ville Syrjälä]

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.

Let's cc the linux-input list...

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