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@xxxxxxxxx>
> > > >
> > > > 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.
--
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
