microsoft natural keyboard 4000 F10/Spell

[Marko Vojinovic]

On Tuesday 04 August 2009 01:02:00 Frank Cox wrote:
> On Mon, 03 Aug 2009 23:46:37 +0100
>
> Marko Vojinovic wrote:
> > On Monday 03 August 2009 22:06:01 you wrote:
> > > "showkey -s" gives me no output at all when I press F10/Spell.
> >
> > This is because it's USB. From man showkey:
> >
> > "The raw scan codes are available only on AT and PS/2 keyboards"
>
> That's demonstrably inaccurate.  The other keys on this keyboard give me
> results when I press them under "showkey -s".  It's just F10/Spell that has
> no output.

Let me quote man showkey again, this time more completely:

<quote>
The raw scan codes are available only on AT and PS/2 keyboards, and even then 
they are disabled unless the atkbd.softraw=0 kernel parameter is used.  When 
the raw scan codes are not available, the kernel uses a fixed built-in table to 
produce scan codes from keycodes.  Thus, setkeycodes(8) can affect the output 
of showkey in scan code dump mode.
</quote>

Basically, I would say that the USB keyboard does not produce scancodes but 
only keycodes, which are then translated back to scancodes if the application 
specifically asks for them. The translation is done via the fixed table built in 
the kernel.

So what you see in the output of showkey -s is in fact this translation, not 
the scancodes coming from the USB keyboard.

Since you got me interested in this problem, I did some digging of my own, and 
found out that the X server is the one (probably only?) major app that *does 
not* use keycodes, but rather scancodes directly. This describes exactly the 
problem you see, since the kernel table above does not seem to have a scancode 
map of keycode 432. If that gets fixed, your key should start working 
automagically under X, and you will be able to read off the X keycode using 
xev.

Btw, keycodes as read by showkey and keycodes as read by xev need not be the 
same, since X creates a different mapping from scancodes to keycodes than the 
kernel. The former are called "Linux keycodes", and the latter "X keycodes". 
You can read more about that in the appropriate HOWTO:

  http://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO.html

Now, how to fix the missing scancode in the kernel table is a different issue, 
since the table seems hard-coded into the kernel. The above paragraph from man 
showkey *suggests* that it just might be possible to use setkeycodes for your 
advantage, regardless of its intended usage --- find an unused scancode 
sequence, do a

setkeycodes <scancode in hex> 432

and see if this scancode will be recognized by X (using xev). Now, if xev sees 
this scancode, it will assign to it a new, probably different keycode, which 
you can then use in xmodmap. If this works, great. If not, maybe a small patch 
to some kernel source file and a recompile of the kernel would solve it. 
However, I believe this is interesting enough to be reported to the kernel 
developers, either as a bug, a rfe or just a question on their mailing list. 
Just tell them that showkey reports a keycode 432, and there is no matching 
scancode in their keycode-to-scancode mapping table, which renders the key 
unusable under X. Maybe they will provide a proper fix.

If you open a bug against the kernel about this or contact the devs on the 
mailing list, please post a link to that here, I am quite interested in 
following the discussion.

HTH, :-)
Marko