Steven Smith wrote:
>>>> For the SDL part, I'm sorry to repeat it should use scancode instead
>>>> of symbol id ...
>>> I think that would imply that the frontend would need to maintain its
>>> own keymap, yes? What do you think should happen if the system
>> Yes, frontend (domU kernel or X11) should maintain it's own keymap.
>>
>>> running the SDL viewer has e.g. a French keyboard but the virtual
>>> machine is configured with a US keymap? Or have I misunderstood you?
>> If the SDL viewer is using X11 configured with french keyboard, and the
>> virtual
>> machine is configured with US keyboard, the used keymap will be the US one.
>> So
>> when I press 'A' on my keyboard I will have 'Q'.
> That kind of sucks. Not being able to produce every character sucks
> more, but having to configure the keymap in every VM isn't much
> better. It's even better if you consider that with VNC clients the
> client keymap may change while the virtual machine is running.
The keymap may not change while the virtual machine is running: "loadkeys" acts
only on the current console, and for X11, "xmodmap" modifies only the current
display. A desktop like GNOME can manage that too...
>> In fact, with scancode the used keymap will always be the virtual machine
>> one.
>>
>> We can compare the two solutions:
>>
>> 1- GDK symbol based:
>>
>> * keymap is keymap of the backend
>> * we can't translate all symbols
>>
>> for instance, look at these GIF:
>>
>> http://riley.slc.k12.ut.us/images/program_images/Type%20Keyboard%20with%20lower%20letters.gif
>> http://www.sussex.ac.uk/its/facilities/pc/keyboards/french.gif
>>
>> On my french keyboard I want to produce "&", so I press "&", GDK table of
>> sdlfb
>> translates it to nothing... (it's true for &é"{(-è_çà)=<> ). If I want to
>> produce "1", I press shift + "&" and I obtain nothing too.. so all symbols
>> and
>> digits are missing !
>> But if you add "&" in your table, it will be good for french keyboard but bad
>> for US keyboard (you will generate "7" instead of "1"...)
> I can't see why just adding SDLK_AMPERSAND to the table will break US
> keyboards. Surely SDL doesn't expect every application to track the
> effects of the shift key?
Look at the GIFs...
if you think "US Keyboard", SDLK_AMPERSAND will be translated to KEY_7, if you
think "French Keyboard", SDLK_AMPERSAND should be translated to KEY_1.
>> And how do you manage this one:
>>
>> http://jcmc.indiana.edu/vol9/issue1/Japanese_Keyboard.gif
> Perhaps we should be using the keysym->unicode rather than
> keysym->sym? I have to admit I'm not sure exactly how the more exotic
> keymaps are actually encoded in Linux, but there must be some way of
> mapping them to keysyms, or such keyboards wouldn't work at all.
Are you ready to manage a table of 2^16 entries ???? ;-)
> Actually, it might be nice to send unicode characters over the
> protocol directly, rather than Linux key codes, and then do the
> translation in the front end.
Perhaps...
>> 2- GDK scancode based:
>>
>> * keymap is keymap of the frontend
> And has potentially no relationship to the ``correct'' keymap, which
> is the one seen by the client.
>
>> * frontend knows how to translate ALL scancodes to a symbols.
> But it occasionally gets it wrong.
Really ? In which cases ?
>> This is the method generally used in emulators (I took scancode from
>> basiliskII)
>> basiliskII:
>> http://www.cebix.net/viewcvs/cebix/BasiliskII/src/SDL/keycodes?rev=1.4
>> Aranym:
>> http://www.sophics.cz/cgi-bin/viewcvs.cgi/aranym/src/input.cpp
> If you're doing full emulation then the guest expects to see a real
> keyboard with real scancodes, and so you don't have a great deal of
> choice.
Yes, but linux kernel expects a scancode too...
>> But if you don't want to use scancode, you should manage all keyboard
>> internally
>> as in E-UAE (file e-uae-0.8.29-WIP3/src/gfx-sdl/sdlkeys.c):
>> http://www.rcdrummond.net/uae/e-uae-0.8.29-WIP3/e-uae-0.8.29-WIP3.tar.bz2
> That's kind of icky as well. Needing to know the user's exact
> keyboard type is really quite unpleasant.
I agree.
> Steven.
Laurent
--
Laurent.Vivier@xxxxxxxx
Bull, Architect of an Open World (TM)
+----- "Any sufficiently advanced technology is ----+
| indistinguishable from magic." - Arthur C. Clarke |
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home
