On Tue, Nov 10, 2009 at 01:04:19PM +0200, Artem Bityutskiy wrote: > On Mon, 2009-11-09 at 09:18 -0800, Dmitry Torokhov wrote: > > > > I am not sure at what level these attributes must be created. While the > > easiest way is indeed per-input device attribute (for that particular > > driver) the functionality does not really have anything to do with > > input... I'd probably prefer having this attribute elsewhere, maybe > > we should extend /sys/class/gpio/gpioN for these purposes? > > > > > * could you please give an example of how would I switch off, say, the > > > SW_CAMERA_LENS_COVER gpio by the keycode. > > > > If the code lies in your driver then it is easy (the driver knows the > > mapping); otherwsie you'll have to go with GPIO number. > > GPIO numbers are bad for us. We want to work with keycodes, and this is > input subsystem after all. We do not want to do any perversions like > making our user-space figuring out gpio numbers by the keycodes. This is > simply wrong and bad interface. > > We want to have a simple way for the application to disable any key by > key code. This should be as simple as calling one single > "enable/disable" ioctl for /dev/input/event2. I do not see how this > could be done nicely with sysfs, still. > I understand the appeal of working with the keycodes but what you are asking is not simply ignoring certain keypresses (that is easy, just ignore corresponding events in userspace), you want to prevent system from waking up. In other words you want to "control PM layer through input layer" and I believe this is wrong. -- Dmitry -- 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
