Thread (4 messages) flat view 4 messages, 2 authors, 2012-12-16

Re: [PATCH RFC] Add support for the matrix keyboard used in Bachmann's OT200

From: Christian Gmeiner <christian.gmeiner@gmail.com>
Date: 2012-12-16 13:33:34

2012/12/13 Christian Gmeiner [off-list ref]:
Hi Dmitry,
quoted
On Wed, Dec 12, 2012 at 02:35:41PM +0100, Christian Gmeiner wrote:
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help