On Wed, Nov 11, 2009 at 08:50:11AM +0200, Artem Bityutskiy wrote: > On Tue, 2009-11-10 at 09:19 -0800, Dmitry Torokhov wrote: > > 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. > > Err, this is really about disabling keys. If you want to stop delivery of certain keycodes to userspace then OK, an option to subscrbe to certain events only instead of getting all events from the device. But again, it will only work for that particular user only, not everyone. > If we think about this in an > abstract way, you have an input device with many keys. And the device's > HW allows you to disable any of it's keys. When you disable the key, the > input device ignores it and does not generate any interrupt for it. And the reason you want to stop interrupts? -- 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
