[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <96C9D994977DD0439FB6D3FE3B13DD907DC3DCC241@BGMAIL01.nvidia.com>
Date: Thu, 19 Jan 2012 13:09:24 +0530
From: Laxman Dewangan <ldewangan@...dia.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
CC: "tsoni@...eaurora.org" <tsoni@...eaurora.org>,
"kyle.manna@...l7.com" <kyle.manna@...l7.com>,
"aghayal@...eaurora.org" <aghayal@...eaurora.org>,
"vapier@...too.org" <vapier@...too.org>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH V1] input: keyboard: Add interrupt keyboard driver.
On Thursday, January 19, 2012 1:00 PM, Dmitry Torokhov wrote:
> On Tue, Jan 17, 2012 at 11:11:55AM +0530, Laxman Dewangan wrote:
> > This driver enables the key detection of the keys which
> > are connected to interrupt lines.
> > Each key is capable of generating an interrupt, and the
> > statesi (pressed or released) cannot be found by any
> > mechanism.
> > A key press event generated when interrupt occurs, and
> > based on the debounce time setting, a key release event
> > is generated. There is no need to read the state of the
> > keys.
>
>
> Is it possible to modify gpio_keys to skip requesting and settin up
> certain gpios and and use it instead of a brand new driver?
I first tried this approach and found that this makes the gpio_keys
driver very complex because almost all places where gpio-apis are
getting called need to put under if condition.
Also there is some special handling for auto key release events
Which makes gpio-key driver again complex.
>
> --
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists