On Mon, 2009-11-09 at 09:18 -0800, Dmitry Torokhov wrote: > Hi Artem, > > On Mon, Nov 09, 2009 at 05:09:04PM +0200, Artem Bityutskiy wrote: > > On Thu, 2009-11-05 at 23:52 -0800, Dmitry Torokhov wrote: > > > On Wed, Nov 04, 2009 at 11:25:59AM +0200, Artem Bityutskiy wrote: > > > > > > > I think registering a full-blown device for every key is way too much, > > > > > > > given that most consumers of gpio-keys driver are embedded... Besides, I > > > > > > > don't think this should be driven from userspace. Board (platform) code > > > > > > > should know what GPIO make sense as wake up sources for the particular > > > > > > > device and should set up platform data accordingly. > > > > > > > > For example, on N900 we want to disable the lens cover / proximity / etc > > > > gpios when the phones' screen is locked. Simply because we do not want > > > > the lines to generate interrupts, wakes up the CPU and waste our battery > > > > energy. But we do not want to disable the screen lock gpio, and some > > > > incoming call related gpios. > > > > > > > > So we really do want this to be userspace-driven. > > > > > > > > > > OK, then maybe we should use 2 attributes, one showing gpios that can > > > be used for wakeup and one showing gpios that are currently set up as > > > wakeup sources. These can be built on using bitmap_scnlistprintf() and > > > bitmap_parselist() and can work with either GPIO numbers or keycodes. > > > > Hi Dmitry, > > > > could you please elaborate some more? > > > > * are you talking about per-input device sysfs files? > > 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. But we will try to come up with some solution. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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
