On Thu, May 7, 2009 at 6:29 PM, Eric Miao <eric.y.miao@xxxxxxxxx> wrote: > On Thu, May 7, 2009 at 4:51 PM, Trilok Soni <soni.trilok@xxxxxxxxx> wrote: >> Hi Eric, >> >> On Thu, May 7, 2009 at 2:18 PM, Eric Miao <eric.y.miao@xxxxxxxxx> wrote: >>> On Thu, May 7, 2009 at 4:41 PM, Trilok Soni <soni.trilok@xxxxxxxxx> wrote: >>>> Hi Eric, >>>> >>>> On Thu, May 7, 2009 at 1:30 PM, Eric Miao <eric.y.miao@xxxxxxxxx> wrote: >>>>> Original patch by Marek Vasut, modified by Eric in: >>>>> >>>>> 1. use delayed work to simplify the debouncing >>>>> 2. build keycode array for fast lookup >>>>> 3. combine col_polarity/row_polarity into a single active_low field >>>>> (are there some cases where the GPIOs are externally connected >>>>> with an inverter and thus causing two different polarity requirement??) >>>>> 4. use a generic bit array based XOR algorithm to detect key press/release, >>>>> which should make the column assertion time shorter and code a bit >>>>> cleaner >>>>> 5. remove the ALT_FN handling, which is no way generic, the ALT_FN >>>>> key should be treated as no different from other keys, and translation >>>>> will be done by user space by commands like 'loadkeys'. >>>>> >>>>> Patch tested on Littleton/PXA310 (though PXA310 has a dedicate keypad >>>>> controller, I have to configure those pins as generic GPIO to use this >>>>> driver, works quite well, though ;-) >>>> >>>> Any support about removing/clearing ghost/phantom keys? Also we assume >>>> that all gpios in the matrix should be able to generate interrupts so >>>> no polldev support required. >>>> >>> >>> Is there some info about such ghost/phantom keys? Otherwise I'll >>> assume these are something like sticky control keys? >>> >>> I'm not sure if there're any such support in console tools and in >>> input subsystem. Hard to say... >>> >>> And the comments below are of great value, I'll incorporate these >>> suggestions in later submission. Thanks very much. >>> >> >> Could you please have look at following gpio_matrix driver? >> >> gpio_matrix.c: >> http://android.git.kernel.org/?p=kernel/msm.git;a=blob;f=drivers/input/misc/gpio_matrix.c;h=c1f47651a4937d5c976a9625ca5da389dd7e4a7c;hb=HEAD >> >> gpio_input.c: >> http://android.git.kernel.org/?p=kernel/msm.git;a=blob;f=drivers/input/misc/gpio_input.c;h=7e307f267a2a059b64a3fb9c8a379b149016b2f8;hb=HEAD >> > > Mmm... looks not so generic, though. And I still have no idea > about how its phantom key works unless I see its hw. > There should be no hardware specific code in those drivers, and you are free to use them. If you remove the early suspend and wakelock code and replace disable_irq with disable_irq_nosync it may cover your needs. We used to have a separate gpio_matrix (and gpio_keys) like you are proposing to add, but it proved to be too limited since the hardware vendors like to mix direct gpio keys and and matrix keys in the same logical keypad. For the phantom key problem, this occurs with most matrix based keypads/keyboards. For instance, you press two keys in the same row then a third key in another row, but in the same column as one of the first two keys. The driver cannot tell which of the two column you pressed since the current will flow through the first two keys to or from the other column. If you do not have any code to detect this you will report four keys down. -- Arve Hjønnevåg -- 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
