Re: keyboard raw mode

[Jan-Benedict Glaw <jbglaw@lug-owl.de>]

[-- Attachment #1: Type: text/plain, Size: 3774 bytes --]

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));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]