Hi all,
Attached (webmail interface sucks) is a long and detailed
description about current problems with internet / east
access keys, a proposed solution and description of some
patches I'm working on.
Please read this (long) and respond as I really would like
to see this get included into F-8.
Regards,
Hans
p.s.
I forget to tell in the attached text that work is being
done with HAL, to automatically call setkeycodes for
laptops based on the DMI info of the laptop motherboard, as
this is a case where we can actually identify the keyboard
manufacturer and model of a ps/2 keyboard.
This means that for the example non microsoft compatible
keyboard used in the attachment things will work out of the
box without needing any end user configuration. For older /
rare non microsoft standalone keyboards manual
configuration will still be needed though.
Hi all,
As I already mentioned in my Fedora 8 ideas mail, one of the things I've
been thinking about and also actively working on is getting easy access /
internet keys to work out of the box (keys like volume up / down, play,
homepage, email, etc). From now on this mail will reference these keys as
"extra" keys.
Actually most parts are already there and its just a matter of properly
configuring things for the most part.
In the next part of this mail I'll first describe the problem, then how things
used to work under the Linux 2.4 kernel, currently don't work under the 2.6
kernel, and how the situation should be under the 2.6 kernel to make things
work even better then they did under 2.4 . Then I'll propose a number of
changes to various configurations to make this reality.
2 Problems
----------
There are 2 problems, the big problem is that when these extra keys started
showing ups on ps/2 keyboards, manufacturers didn't create a standard, but
instead everyone decided on itself which still free scancodes to use for
which key. Since one cannot detect which brand/model ps/2 keyboard is
connected, this means that the user will always need to configure this
through some kinda gui. Luckily Microsoft has published a document in which
they advice which scancodes to use for which extra keys, not only their own
keyboards use these scancodes, but since windows will work with these out of
the box, also most newer ps/2 keyboards from other manufacturers follow this.
The 2.6 kernel assumes a microsoft compatible keyboard by default, so with such a
keyboards things should just work (but they don't, see below).
The other problem is that the scancodes from a keyboard pass through many
layers of translation before reaching an X (GNOME/KDE) app, more on this
below.
The 2.4 kernel days
-------------------
Unlike the 2.6 kernel, the 2.4 kernel didn't do any translation on
scancodes, sending them directly to X.
For some time X didn't know what todo with these and special tools like
lineak were needed to be able to use these keys. Later Stanislav Brabec
(from SUSE) translated all the available lineak configs to
/usr/share/X11/xkb/symbols/inet, allowing one to select a keyboard model of
for example "compaq armada laptop" or "microsoft wireless internet
/keyboard".
He also created special X-keysyms like XF86HomePage for these keys. So when
a user now selected the correct keyboard model (through GNOME / KDE
keyboards preferences for example) X would generate these special X-keysyms
for his special keys. The user then only needed to configure apps to
recognise these, through for example his window-manager shortcut keys
configuration.
The 2.6 kernel days
-------------------
The 2.6 kernel brought a new input subsystem with it. This subsystem no
longer thinks in scancodes, but rather thinks in keycodes, which are defined
in /usr/include/linux/input.h . This is a good thing, as for example USB
keyboards do not have scancodes and USB keyboards do have a real standard
for extra keys, allowing the kernel to always send the correct keycode for
an extra key. For ps/2 keyboards the kernel translates the scancodes from
the ps/2 keyboard to keycodes, assuming microsoft compatible scancodes for
extra keys by default. This can be changed by using setkeycode.
However many apps, including Xorg as it is currently configured under Fedora,
still think in scancodes. For these applications the kernel will translate
the keycodes it internally uses back to scancodes, using a fixed (non
configurable) translation model generating microsoft compatible scancodes
for extra keys.
An example of how things used to be and are now
-----------------------------------------------
On my Compaq N600c laptop I have 4 extra keys, below is a table, with the
Icon's on the key, the scancode's generated and the X-keysym's generated
when using a 2.4 kernel and selecting "Compaq armada laptop" as keyboard
model in X:
Icon on key Scancode X-keysym
I(nternet) e0 23 XF86WWW
Mail e0 1e XF86Mail
Home e0 1f XF86HomePage
Looking Glass e0 1a XF86Search
When I use this laptop with the 2.6 kernel, whenever I press one of the 4
keys, the following messages show up in dmesg (and nothing happens):
atkbd.c: Unknown key pressed (translated set 2, code 0x9f on isa0060/serio0).
atkbd.c: Use 'setkeycodes e01f <keycode>' to make it known.
This happens because the scancodes send by the extra keys on my laptop are
not part of the microsoft compatible set of scancodes, and thus the kernel
does not have a default scancode -> keycode translation for them.
Thus I issue setkeycodes command for all 4 keys on my laptop. However,
remember how X will now get fake scancodes, which are made by translating
the internal keycodes to microsoft compatible scancodes, this results in the
following happening:
Icon on key Scancode Linux keycode Fake scancode received by X
I(nternet) e0 23 150 / KEY_WWW e0 02
Mail e0 1e 155 / KEY_MAIL e0 6c
Home e0 1f 172 / KEY_HOMEPAGE e0 32
Looking Glass e0 1a 217 / KEY_SEARCH e0 e5
Notice how X now receives scancodes which are very much DIFFERENT from the
real scancodes !!
This can be worked around by telling the kernel to skip the double translation
steps for ps/2 keyboards, by setting the softraw sysfs attribute of the atkbd
input device to 0. However this is frowned upon by the upstream kernel input
system maintainers, and they will NOT change the default for softraw from 1
to 0, thus I believe we shouldn't either.
There are also good technical reasons not todo this. What if I'm using softraw
0 and plugin an USB-keyboard, that will then still send microsoft compatible
fake scancodes (there is no softraw for USB keyboards, as the don't have real
scancodes, only fake ones). Which will cause X to receive 2 different sets
of scancodes for the same key. What if I plugin USB speakers, if those
speakers have volume buttons, those will also show up as a "keyboard" with
extra keys using microsoft compatible fake scancodes.
The solution
------------
Actually although thinks look worse with the 2.6 kernel at a first glance,
things are actually better. Since X now sees only fake scancodes, always
emulating microsoft compatible extra keys, things become much easier. All we
need todo is to teach X (through xkb configuration) that the keyboard it now
sees is not just a 105 key generic keyboard, but a 105 key generic keyboard
with microsoft compatible extra keys. When X has been thought this (and apps
configured to recognise the special X-keysyms) USB devices and microsoft
compatible (iow most) keyboards, will just work.
The only problem is non-microsoft compatible ps/2 keyboards, like the extra
keys on my laptop, for those setkeycodes will need to be run. We need to
write some sort of new configtool for this, allowing people to select from a
premade list of keyboard configs, and if necessary to create there own config
key by key, all nice gui based ofcourse.
The plan / todo
---------------
1) Fix the kernel to be 100% consist with microsoft compat keyboards in ps/2
versus USB connection.
-The kernel currently sends KEY_FIND for the looking glass key when
connected through USB, where as this key gets mapped to KEY_SEARCH
when connected through ps/2. This is because of a bug in the USB mapping
where it deviates from the USB HUT standard, a patch has been send and
merged for this upstream
-The kernel currently sends KEY_WWW for the key with the Home icon when
connected through ps/2, in the USB case it correctly sends KEY_HOMEPAGE
a patch has been send upstream for this. Upstream has agreed that this
is correct, but not yet merged the patch (AFAIK).
2) Modify /usr/share/X11/xkb/symbols/pc, to recognise the microsoft
compatible scancodes* for extra keys, as part of the generic 104 key and
generic 105 key keyboard models.
Doing it this way means that people who have not changed the keyboard model
from the default will automatically get these X-keysym mappings, without
requiring any magic to change xorg.conf. Also people who have choicen a
different model (and thus possibly are using softraw = 0), will not be
affected by the new mappings this way, avoiding any regressions for
people who have already made configuration changes themselves to get
things to work.
-I'm working on a patch for this and will a file a BZ ticket with this
patch soon.
Note: Stanislav Brabec who created /usr/share/X11/xkb/symbols/inet is
currently working on an xkb patch which will create a virtual linux
keyboard model. However his works assumes using the evdev driver of xorg,
which we currently don't (I don't know if there are plans for this), and
his work is much more invasive, also its unknown if this will be ready
for F8-test2 .
* the X internal keycodes for the scancodes actually, but thats a
technicallity not important for this discussion.
3) Teach apps about the extra keys X-keysyms. For example metacity has
actions which can be bound to hotkeys for many of the things for which
keyboards have extra keys, but the default bindings for these keys are
empty, instead of being bound to the extra keys X-keysyms by default.
I'll create BZ tickets for atleast metacity and possibly patches too, but
thats not going to happen the coming week, help with this would be much
appreciated.
Regards,
Hans
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
