microsoft natural keyboard 4000 F10/Spell
Marko Vojinovic
vvmarko at gmail.com
Tue Aug 4 04:02:07 UTC 2009
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
More information about the fedora-list
mailing list