keyboard raw mode

keyboard raw mode

[Congjun Yang]

I have a special POS keyboard that comes with a
magnetic swipe reader. When a card is swiped, the
keyboard prefixes the card data with a seqneuce
starting with "1d 9d 9d". I guess this design is to
allow applications to tell card swipes from key
presses, as the two left control break codes "9d 9d"
cannot be generated from key presses.

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.

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.

Along the same line, why would atkbd.c complain about
"Unknown key code..." when an unknown key is pressed
in raw mode (e.g. "showkey -s")? It shouldn't care if
I just want to get the scan codes, should it? I have
to do setkeycodes before I can see the scan codes!?




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: keyboard raw mode

[Jan-Benedict Glaw]

[-- 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 --]

Re: keyboard raw mode

[Dmitry Torokhov]

On Saturday 01 July 2006 05:55, Jan-Benedict Glaw wrote:
>   * All protocol drivers (eg. the atkbd driver) will *never* ever
>     stuff the raw I/O anywhere.

Actually some of them do via EV_MSC/MSC_RAW events. So raw code should be
available through evdev nodes and also on x86 keyboard driver in raw mode
should also pass raw data through (from atkbd only).

Congjun, what 2.6.x kernel have you tried?

-- 
Dmitry

Re: keyboard raw mode

[Congjun Yang]

2.6.9-22.EL(CentOS 4.2) is what I currently use.
2.4.20 was where I first saw, in keyboard.c, the
workaround that throws away a second break code.

I think I like the new design for the user input
system: separate the protocol layer from the raw port.
But, would it be nice for the atkbd driver to still
provide a raw (or passthrough) mode?

Thanks,
Congjun Yang

--- Dmitry Torokhov <dtor@insightbb.com> wrote:

> On Saturday 01 July 2006 05:55, Jan-Benedict Glaw
> wrote:
> >   * All protocol drivers (eg. the atkbd driver)
> will *never* ever
> >     stuff the raw I/O anywhere.
> 
> Actually some of them do via EV_MSC/MSC_RAW events.
> So raw code should be
> available through evdev nodes and also on x86
> keyboard driver in raw mode
> should also pass raw data through (from atkbd only).
> 
> Congjun, what 2.6.x kernel have you tried?
> 
> -- 
> Dmitry
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: keyboard raw mode

[Dmitry Torokhov]

On Sunday 02 July 2006 04:21, Congjun Yang wrote:
> 2.6.9-22.EL(CentOS 4.2) is what I currently use.
> 2.4.20 was where I first saw, in keyboard.c, the
> workaround that throws away a second break code.
> 

I think it should work in 2.6.9... The change was put in in summer
of 2004, 2.6.9 was released in fall...

Try booting with atkbd.softraw=0 to turn off software rawmode
emulation and I think you will see all the codes from your
device.

> I think I like the new design for the user input
> system: separate the protocol layer from the raw port.
> But, would it be nice for the atkbd driver to still
> provide a raw (or passthrough) mode?
> 

It does ;)

-- 
Dmitry

Re: keyboard raw mode

[Congjun Yang]

AWESOME!!! (except that atkbd still complains about
unknown keycodes;)

--- Dmitry Torokhov <dtor@insightbb.com> wrote:

> On Sunday 02 July 2006 04:21, Congjun Yang wrote:
> > 2.6.9-22.EL(CentOS 4.2) is what I currently use.
> > 2.4.20 was where I first saw, in keyboard.c, the
> > workaround that throws away a second break code.
> > 
> 
> I think it should work in 2.6.9... The change was
> put in in summer
> of 2004, 2.6.9 was released in fall...
> 
> Try booting with atkbd.softraw=0 to turn off
> software rawmode
> emulation and I think you will see all the codes
> from your
> device.
> 
> > I think I like the new design for the user input
> > system: separate the protocol layer from the raw
> port.
> > But, would it be nice for the atkbd driver to
> still
> > provide a raw (or passthrough) mode?
> > 
> 
> It does ;)
> 
> -- 
> Dmitry
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com