lkml.org 
[lkml]   [2006]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: keyboard raw mode
On Fri, 2006-06-30 22:00:23 -0700, Congjun Yang <congjuny@yahoo.com> wrote:
> The keyboard worked fine with kernel 2.4.7. If I put
> the keyboard in raw mode, I can receive the sequence
> "1d 9d 9d". A simple test can be done with "showkey
> -s". However, newer kernels seem to treat the second
> break code as a hardware error, which in my case it's
> not, and simply discard it.

This is because the whole user input handling was reworked in the mean
time.

For keyboards, things are like this:

* A low-level port driver implements a serial endpoint. For PCs,
this are the keyboard and aux channel of the keyboard controller
i8240. These are called serio ports.
* Protocol drivers can be hooked up to these serio ports and
communicate with the actual hardware. This is eg. a driver for AT
keyboards or a PS2 mouse.
* All protocol drivers (eg. the atkbd driver) will *never* ever
stuff the raw I/O anywhere. They interpret the stream and push
commonly used values into Linux's Input API. That is, if you press
the "A" button on *any* keyboard, all drivers will issue a KEY_A
event and never ever tell about the specific raw keycodes
received.
* If you talk to the old /dev/psaux interface, of if you use the raw
mode for keyboard reading, then the formerly issued KEY_A event is
translated back to the raw sequence. Of course, non-recognized
events (like two break codes) cannot be emulated, so this doesn't
work at all.

> While it's necessary to have a work around for certain
> hardwares that tender to produce such errors, but why
> would the fix be done at "raw" level? In raw mode, I
> would expect to receive whatever is generated from the
> keyboard, including possibly errors. If I decide to
> put the keyboard in raw mode, I assume the
> responsibility of handling raw data.

There's no direct raw level anymore; it's the result of emulation
these days.

There are two solutions:

* Throw away the atkbd driver. That means there's no more a
"keyboard" from the system point of view. Write a small daemon
that uses the serio_raw driver to get the raw I/O coming from the
keyboard and make it interpret it. Don't forget to also do atkbd's
work and parse the "normal" keyboard I/O, too, and issue the KEY_A
(and all the other) events to the kernel using the uinput driver.
* Write a filter driver for your keyboard. (Actually, write two.)
I've done that some time ago, with some luck you'll find it. If
not, that's probably lost (was just a test:-)
Such a driver is both, a protocol driver and a serio driver. As a
protocol driver, it accesses a serio port and relays the read data
to a second driver (which should in your case parse the MSR data
and relay it to some userland applications). Anything that's not
specific to the POS functions (non-standard beeps, MSC, barcode
scanner, background light, LCD display, ...) should be given back
to the first driver, which (serio half) also registers a new serio
port to be useable by atkbd.

I'm not sure what the best variant is. The first one is a bit easier
to implement, but if you fsck up your daemon, you no longer have a
keyboard:-) The second one is a bit harder to implement, but you can
reuse the atkbd driver. As I said, that was already written once and
proved to work.

MfG, JBG

--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2006-07-02 00:06    [W:0.075 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site