Red Hat Bugzilla – Bug 245576
PATCH: make generic 104/105 key model recognise linux virtual keyb. "extra" keys
Last modified: 2008-05-01 05:32:00 EDT
Quick intro I'm a fedora contributor, who has lately been working on making
internet / easy access / multimedia keys work out of the box for Fedora 8.
I've written a (somewhat long) mail to the devel list, with the results of my
investigation into this area, and a plan howto make these keys work out of the
box with minimal changes (and thus with minimal chance for regrressions). For
this mail see:
Please read this, as it explains the how and why of this patch.
Attached is a patch, which as explained in the mail makes the generic 104 and
105 key keyb models recognise the (emulated) scancodes for extra keys the Linux
kernel sends. Since the kernel now a days shows an emulated keyboard to X and
not the real one, and since this emulated keyb includes extra keys, with well
defined scancodes for them, I believe the generic models should recognise the
scancodes for these keys on the Virtual Linux keyboard X sees now a days.
Created attachment 157761 [details]
PATCH: make generic 104/105 key model recognise linux virtual keyb. "extra" keys
Kristian, I know you've been busy with the font changes, and it hasn't been all
that long. But any chance you could take a look at this and tell me what you
think of the suggested fix / patch? I would like to get this fixed in F-8 and
since this may need some discussion before coming up with a final fix, I would
like to see things moving.
(In reply to comment #2)
> Kristian, I know you've been busy with the font changes, and it hasn't been all
> that long. But any chance you could take a look at this and tell me what you
> think of the suggested fix / patch? I would like to get this fixed in F-8 and
> since this may need some discussion before coming up with a final fix, I would
> like to see things moving.
Hi Hans. I took a look, and my first thought is that this kind of change should
go through upstream. Also, as I understand your patch, the kernel will
translate all the extended key codes that different keyboards generate to one
set of extended key codes (microsoft). The mapping between whichever codes the
keyboard generate and the microsoft codes is set up with setkeycodes, but when
and where is that done? How does the user specify which mapping to use? As far
as I understand, the user still has to specify a keyboard model somewhere, which
in the end doesn't really improve the end-user experience.
(In reply to comment #3)
> Hi Hans. I took a look, and my first thought is that this kind of change should
> go through upstream.
I've been in touch over the last couple of weeks with Linux-input upstream
(Stanislav Brabec & Vojtech Pavlik) about this for a while, but I think you mean
xkb database upstream. I don't think this patch is suitable for upstream as its
an intermediate solution until Xorg switches to using evdev by default, however
to quote Stanislav Brabec on this (evdev): "it is probably not yet ready for
Another reason not to take this upstream is because its Linux specific, as I've
tried to explain already, the 2.6 kernel emulates a ps/2 keyboard called the
"virtual linux keyboard", so X no longer sees a real ps/2 keyboard, but the
virtual one (which is esp. clear in the USB keyboard case).
So a patch suitable for sending upstream, would require the addition of a "Linux
virtual keyboard" model to xkb, as I don't think that adding these
scancode->symbol mappings to the generic keyb models will be acceptable for
freebsd / openbsd / xxx. However then we need to write scripts to update
existing xorg.conf files to switch to this keyb. model, and teach the various
tools who touch xorg.conf about this. So just adding mapping for the extra keys
scancodes to the generic 104 / 105 key models is the easier solution, and I
think that it also is better from a user POV, I don't think a user will
understand it when his keyb is described as a "linux virtual keyboard" in the
> Also, as I understand your patch, the kernel will
> translate all the extended key codes that different keyboards generate to one
> set of extended key codes (microsoft). The mapping between whichever codes the
> keyboard generate and the microsoft codes is set up with setkeycodes, but when
> and where is that done? How does the user specify which mapping to use? As far
> as I understand, the user still has to specify a keyboard model somewhere, which
> in the end doesn't really improve the end-user experience.
I see your problem, but your interpretation is a bit off. The kernel by default
will do the right thing for usb keyboards and for keyboards with microsoft
compatible extra keys. So setkeycodes is only needed as an exception not as a
rule, if you look at symbols/inet then you will find that about 90% of all
keyboards there have ms compatible keys. The only problematic ones are some
older compaq keyboards and ibm rapid access keyboards, but those ibm's ones will
only work if you first send a special command to enable the extra keys, so those
don't count really)
Thus for most users, the use of setkeycodes _really_ is not necessary. If you
currently plug in a ps/2 keyboard with microsoft compatible keys (I bought 2 el
cheapo keyboards with extra keys for testing this and the both are ms compat) or
any usb keyboard, then the kernel will do the right thing.
However X currently will not generate any keysym's for the special keys as it
doesn't recognise the keycodes.
So without my patch the test sequence is:
extra keys generate events, but without keysym's
With my patch:
extra keys generate events, including correct keysym
Last about the exceptional keyboards, which do need setkeycodes, this are
already broken at the moment with F-7, for example I have an older Compaq keyb
with extra keys, and when I plug this in, the kernel doesn't recognise the extra
keys as those generate scancodes not generated by ms compatible keyboards. Since
the kernel doesn't recognise the keys, it completely discards any events related
This can be fixed by calling setkeycodes, after which X still needs to be tought
to recognise the fake scancodes generated by the kernel for this keys (as is
done by my patch), or one can turn of softraw with a cryptic command like:
echo -n 0 > /sys/class/input1/device/softraw
After which X will get the real scancodes for all keys, then the user can go to
the keyboard preferences and select his keyb model there if it is listed in
symbols/inet, and then things will work, if he is so lucky that the entry in
symbols/inet is correct, as many entries there where made with some kinda
unknown scancode translation table used somewhere, and thus are faulty even when
used with a 2.6 kernel without softraw.
Also disabling softraw to avoid having to use setkeycodes is a bad idea, because
if you then plug in an additional usb keyb (say a full size usb keyb in a
laptop) then there will be different scancodes for the same keys, as the ps/2
keyb on the laptop will send the real scancode for for example its "homepage"
key, where as the kernel will send a fake scancode for the same key on the USB keyb.
So you see a non microsoft compat ps/2 keyb user will always have trouble
involving magic commands, no matter how we solve this, but with my patch most
ps/2 keyboards and all usb keyboards will just work (as in generate the correct
Also according to linux-input upstream, evdev is the future, and with evdev
setkeycodes will be needed in the exceptional ps/2 case, just like with my patch.
Any chance you can repsond to my long explaination about the why and how of tihs
I've added you to the CC, as you are very much involved in all the hotkey stuff
too, and I think some more / other input would be usefull. What do you think of
the proposed patch as intermediate solution to the keycode -> keysym mapping in
X. I know this isn't the final solution, but this will make X send the correct
keysym's for properly setup keyboards, in as far as there are defined keysyms
for them, and will make X do that now. I think this is worthwhile, because its a
very simple patch with close to zero chance of causing regressions, and I want X
to start sending keysyms for the most found keys now, so that I can start
working on adding support to applications. I do realize that evdev is the
future, but that will not be ready before F-8. And since evdev is the future
I've no intention to spend (much) time on some of the more elaborate solutions
like adding a "linux virtual keyboard" model to xkb and scripts to patch
xorg.conf to switch to this model.
I believe that getting patches accepted in applications will be much easier if
the keysym's the patch uses actually get generated. Otherwise I might have a
hardtime convincing other maintainers / upstream.
I believe that all this is worthwhile / worth the effort, since this
intermediate solution patch is simple and already done, and all the application
work is usefull for evdev too, since in the evdev case the already existing
special key keysyms used in this patch will stay in use.
// key <I14> no keysym for a "Alternate Erase" button
"Alt Eraze" should be mapped to "backspace" and (in a perfect world) there
should be an option to map it to "space" as it is used for the "Erease Eaze
(tm)" key which is left part of the space bar.
If this makes my multimedia keys JustWork under F8 - I'm all for it. Please
include this patch.
Closing this as new us+inet layout used in F-8 and F-9 fixes most of these (not
all though) and we're moving to evdev for F-10 anyways.