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? * could you please give an example of how would I switch off, say, the SW_CAMERA_LENS_COVER gpio by the keycode. * why this should be sysfs and not a new ioctl? * should this be something specific to gpio-keys or common for all devices? Thanks. -- 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
