2009/5/25 Trilok Soni <soni.trilok@xxxxxxxxx>: > 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? > Yes, that will be good. Dmitry, Could you have a quick look and get some feedback to us, so that we can still have time to fix and get this into the next merge window hopefully? -- 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
