Re: [RFC PATCH 1/1] Input: gpio-keys: export gpio key information through sysfs

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Wed, Nov 04, 2009 at 11:25:59AM +0200, Artem Bityutskiy wrote:
> On Wed, 2009-11-04 at 11:06 +0200, Mika Westerberg wrote:
> > On Wed, Oct 28, 2009 at 12:50:01PM +0200, Mika Westerberg wrote:
> > > Hi,
> > > 
> > > On Wed, Oct 28, 2009 at 06:43:17AM +0100, ext Dmitry Torokhov wrote:
> > > > 
> > > > On Fri, Oct 23, 2009 at 03:15:46PM +0300, Mika Westerberg wrote:
> > > > > From: Mika Westerberg <ext-mika.1.westerberg@nokia.com>
> > > > > 
> > > > > In some embedded devices gpio lines are used as keys/buttons
> > > > > through input layer and gpio-keys.  It is, however, impossible
> > > > > to disable gpio lines separately from waking up the cpu.  For
> > > > > example when device is locked we don't want accidental camera
> > > > > button press to cause the device to wakeup just to notice that
> > > > > it should continue sleeping.
> > > > > 
> > > > > This patch exports gpio-keys through sysfs and allows userland
> > > > > to control whether single gpio line should wakeup the cpu or not.
> > > > > 
> > > > > Sysfs interface is accessible via:
> > > > > 
> > > > > 	/sys/class/input/gpio-keys/input/input0/gpio-key.N/
> > > > > 
> > > > > Following attributes are exported per gpio key:
> > > > > 
> > > > > 	/code    ... input event code (ro)
> > > > > 	/type    ... input event type (ro)
> > > > > 	/desc    ... description of the button (ro)
> > > > > 	/disable ... enable/disable gpio line (rw)
> > > > > 
> > > > > Userspace should be able to find out what key to disable/enable
> > > > > by investigating {code, type, desc} tuple.
> > > > > 
> > > > 
> > > > 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.

-- 
Dmitry