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@xxxxxx http://www.sci.fi/~syrjala/ -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
