I have done some experimenting this evening, and I got standard scan code
to work using /dev/console. It returns raw scan codes, so it works
wonderfully. I won't upload until I get things to work more properly, but
for now, I'll tell you what I did:
On FocusIn event, open the console and start a thread which reads from it,
sending the values to the correct function (can't remember from memory, but
it was something like gen_scancodes)
On FocusOut event, kill the thread and close the console, so other apps can
be used with the keyboard. I'm still very unfamiliar with Unix' threads, so
I pretty sure I'm sending the wrong signal which causes that thread aren't
freed correctly. If someone could help me, I'd appreciate.
I tried it with the FreeDos image, and it works. The bugs I currently
experience are segfaults on plex86 termination, the thread resource leak,
and after many times I try the program, it doesn't acquire the device.
These are probably all related.
I'm wondering if using /dev/console directly has any side effect. I'm not
knowledgeable enough in this field.
EL
At 01:05 2000-12-20 +0100, you wrote:
>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
>
>
