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

From: Artem Bityutskiy <dedekind1@gmail.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Mika Westerberg <mika.westerberg@iki.fi>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>
Subject: Re: [RFC PATCH 1/1] Input: gpio-keys: export gpio key information through sysfs
Date: Wed, 11 Nov 2009 08:50:11 +0200	[thread overview]
Message-ID: <1257922211.21596.823.camel@localhost> (raw)
In-Reply-To: <20091110171945.GA15263@core.coreip.homeip.net>

On Tue, 2009-11-10 at 09:19 -0800, Dmitry Torokhov wrote:
> On Tue, Nov 10, 2009 at 01:04:19PM +0200, Artem Bityutskiy wrote:
> > On Mon, 2009-11-09 at 09:18 -0800, Dmitry Torokhov wrote:
> > > 
> > > 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.
> > 
> 
> I understand the appeal of working with the keycodes but what you are
> asking is not simply ignoring certain keypresses (that is easy, just
> ignore corresponding events in userspace), you want to prevent system
> from waking up. In other words you want to "control PM layer through
> input layer" and I believe this is wrong.

Err, this is really about disabling keys. If we think about this in an
abstract way, you have an input device with many keys. And the device's
HW allows you to disable any of it's keys. When you disable the key, the
input device ignores it and does not generate any interrupt for it.

So this is really about ignoring keycodes but on the driver level, not
at the evdev level. We just want to make evdev pass the ioctl down to
the device. If the device does not support it, it'll return an error.
Otherwise the device will just mask out the key on the HW level.

So it is not about playing evil games with PM, it is just about
disabling separate keys on the HW level. We really can look at this that
way.

For me this looks like a good enough abstraction. And probably this may
be useful for other input devices.

I think Mika had some patch which implements this, right?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html