On Tue, Dec 19, 2000 at 05:15:13PM -0500, Kevin Lawton wrote:
> 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.
I'm all for 2 until I read the remote part :-) And to make things worse,
here are some more nasties:
- The X window manager will try to "help" us by processing certain
keys first (if you use KDE, you cannot use any global keys like
Ctrl-F1 because KWM swallows them before any app sees them). OTOH,
we can try to find out just how KWM does this and use the same
technique to swallow these keys before KWM sees them :-)
- Another problem is that plex86 can loose and get the focus while modifier
keys are depressed. This can irritate the OS running in plex86 because
it will expect that it receives a scan-code "Ctrl is pressed" before it
finds "Ctrl-C" in the input stream (well, actually, the user will
wonder why plex86 will modify all keystrokes with Ctrl when it's not
pressed). The solution here is probably to ignore modifier keyup/down
events but always generate synthetic modifier keyup/down events depending
on the modifier field in the X event.
- Direct access to the X scancodes does not really help. You can
print them with "xmodmap -pk". They look like this:
10 0x0031 (1) 0x002b (plus) 0x007c (bar) 0x00a1 (exclamdown)
The first number is the keycode which you will find in the event and the
other four are: Plain key, key with shift, key with alt, key with shift+alt.
If you read out this map, then you could check what's in the second
column but that gives you no idea where that key actually is.
The solution in AROS is to supply a program in which you press every
key on your keyboard in a certain sequence and this program writes a
map file with the keycodes.
Pro: You can adjust any key. You can create maps for different
computers (ie. when you work remote).
Con: It's a bit tedious (the program is pretty dump). If you make
a mistake, you must do the whole process again.
Neutral: It must be possible to specify this map in the command
line because otherwise, you would have to create lots of config
files for every host you're working on. Another solution would
be a small uname/hostname-check in the config file to select
specific options or something like the menus in config.sys
so you can select a set of options (but then, you cannot have
a global config file).
Maybe a better solution would be to provide the sources to xev
(just a single file) so users can find out the X keycodes of the
keys that don't work and then put this in the config file:
bochs-opt keymap: 10=BX_KEY_1 11=BX_KEY_2...
--
==============================================
Sowatec AG, CH-8330 Pfäffikon (ZH)
Witzbergstr. 7, http://www.sowatec.com
Tel: +41-(0)1-952 55 55
Fax: +41-(0)1-952 55 66
----------------------------------------------
Aaron "Optimizer" Digulla, [EMAIL PROTECTED]
==============================================
