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.
Thanks for the comments.
This was done because setting these from board files is not enough
as this is something that should be dynamically configured. For example
when we lock the device, there are some buttons (gpio lines) that will
wakeup the device but not all of them. When device goes to sleep (but
is not locked) then there are additional buttons that can be used to
wake it up.
We have daemon that does this stuff depending on system state so we
need some way to let userspace to control these.
Do you have any suggestions or alternative ways of doing this? Would
it be beneficial for other consumers to dynamically configure these
lines (maybe not through sysfs but for example via ioctl)?
Thanks,
MW
--
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
