Hello there,
I already made some work in this area, and I'm using a 'trick' which
doesn't fully satisfy me to access X raw scancodes ( SDL uses the same ).
With this approach, you are not dependent on the actual X mappings, and
you can access the raw keyboard codes (which, apart from 1 US key
missing on international keyboards, and 2 Intl keys in addition on
international keyboards, are the same on quite every keyboard).
You can find pieces of my work here (http://ludovic.lange.free.fr/PLEX86 ).
What's missing now is a rewrite of the BIOS to fully support the whole
scancode range and behaviour. I've started to do this, but right now I'm
a little busy and I'll come back to this in a few weeks.
Best regards,
Ludovic LANGE
Kevin Lawton wrote:
> 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
>
