Hi Eric/Arve, 2009/5/8 Arve Hjønnevåg <arve@xxxxxxxxxxx>: > 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. I would suggest that we better move ahead with current gpio_matrix driver submitted by Eric and let's get reviewed by Dmitry. Other features can be added as an when some one needs them. Is that sounds good? -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni -- 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
