2012/12/13 Christian Gmeiner <christian.gmeiner@xxxxxxxxx>: > Hi Dmitry, > >> On Wed, Dec 12, 2012 at 02:35:41PM +0100, Christian Gmeiner wrote: >>> The used matrix keyboard controler (implemented via FPGA) supports >>> two simultaneous key presses. The driver sends the raw register >>> values for each key (row & column) to userspace. >>> >>> In userspace a small tool is running, which reads a 'mapping' >>> file, processes the key events and send the configured keycodes >>> back to the kernel via uinput. >> >> This is a bit roundabout way of doing it. Why can't the kernel driver >> perform lookup in it's internal table and emit proper keycodes itself? > > I thought that T9 can not be done in kernel. The biggest problem is that > I need have separate keys to change the behavior: > > - one key to switch between T9 and normal number input > - one shift key > - one key for caps lock > > This means that I need to have some sort of logic to interpret the same > key differently depending on the operation mode. > Is this possible in the input subsystem? > > If not it should be no problem to send the raw register value back to userspace > and handle it there. > >> We have wealth of options for supplying keymaps to the kernel drivers, >> including: >> >> - platform data >> - device tree data >> - loading from userspace via EVIOCSKEYCODE ioctl. > > For this driver only EVIOCSKEYCODE could be an option as my company > uses the same hardware with different front panels (with different key options). > That is the reason I have a userspace tool that parses simple ini file and do > the logic there. > As I got no feedback I assume that its okay to do all processing in userspace. thanks -- Christian Gmeiner, MSc -- 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
