OK, we should revisit the issues involved with making
international keyboards work in plex86.
Here's a quick overview. Please fill in the gaps in areas
you are familiar with.
Hardware level:
A key press on your keyboard is sensed by the keyboard hardware
and sent to the keyboard controller as a Kscan code. For example
the 'Q' key has Kscan 0x42. For a key release, the release code
0xF0 followed by the key press code 0x42 is sent.
For compatibility with the PC/XT keyboard, keyboard controllers
have the ability to translate this Kscan code to a system scan
code equivalent to what the PC/XT keyboard would generate. In
this example, the Kscan of 0x42 would be translated into a system
scan code of 0x10. Releases are translated the same, with bit7
set, so 0x90 for our example.
If you run the following command on a Linux console (make sure
X is not running, not even on another virtual console), you will
see the raw system scancodes. Press/release the 'Q' key.
linux-> showkey -t 3 -s
0x10 0x90 # pressed/released 'Q'
Software level:
Just about anything can happen here, depending on what software
you are running. Here, the input scan code stream is read in,
and sometimes highly processed before being distributed to
the input of requesting programs. For example, you might press:
[Shift] [A] [release-A] [release-Shift]
which the system may process into capital 'A' for the input
program. This is as opposed to:
[A]
which the system may process into small 'a'. This level is repleat
with the possibilities of various keys performing as modifiers,
or invoking other actions, rather than generating keystrokes to
the a requesting input program.
In X11, the Shift-A seqence above, might generate a key event to
an X application, if it is typed within the application window, and
is requesting key events. In this case, the application has access
to a keycode field in the XKeyEvent and a keysym, neither which
necessarily directly relate to the physical key that was pressed/released.
It is entirely possible, that the software layer can ignore certain
keys, remap them to something completely different, or perform an
action, rather than generate a keystroke event.
For us to correctly virtualize the keyboard, we need to have
enough information to reconstruct the sequence and physicality
of all key events, so that we can feed this information
to the keyboard emulation which (should) only understand physical
key events, not abstract key notions like 'Q'. Otherwise our
keyboard emulation will be highly dependent on one mapping, as
is the current case, the US QWERTY layout.
If we have access to the generated raw system scancode information, then
this is simple. Otherwise we have to look at information
given to us in a more abstracted and processed format, and synthesize
the sequence of keystrokes that must have occurred to evoke the events we
see. For example, if we get an XK_A keysym, the we might assume we got a
[Shift] [A]
Note that this does not give us the physical location of the key, which
we definitely also need. Some ways of solving this:
1) Perhaps there are extentions to X which allow for direct
access to the system scancodes? I saw mention in the X man pages
for XChangeKeyboardDevice. Maybe we could XGrabKeyboard,
and switch over to an alternate device. I'm guessing we'd
have a hard time finding a complete solution here given different
X servers etc.
2) Or after synthesizing what keys were pressed/released, we could
translate them back to physical key locations via some standard maps
which could be customized. Each map would define a translation between
an abstract key, like 'Q', and it's physical location on
the keyboard. Since we can't tie the maps to a particular host,
we'd have to include our own in plex86. Should be able to process
ones in Linux easily though to make ours.
Keep in mind we need a solution or set of solutions which work on all
host OSes. And for X, keep in mind that the window might be on
a differnet machine than the VM.
Now, we could easily feed these physical key events to the keyboard
emulation, which in turn passes Kscan/system scancodes to the guest OS.
The guest OS could then map the keyboard layout any way it wants. This
would allow for both abitrary host keyboard mappings, and arbitrary
guest keyboard mappings. These two mappings would not have to be
the same.
Currently, the keyboard code in plex86 assumes you are operating
on a US QWERTY keryboard layout, when it translates from abstract
key events such as 'q', to the physical location. This is why
using other keyboard layouts does not currently work properly.
Thoughts?
-Kevin
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Kevin Lawton [EMAIL PROTECTED]
MandrakeSoft, Inc. Plex86 developer
http://www.linux-mandrake.com/ http://www.plex86.org/
