Re: [Xen-devel] [PATCH] Paravirt framebuffer backend tools [2/5]

[Steven Smith <sos22-xen@xxxxxxxxxxxxx>]

> >> 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.

> 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?

> 
> 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.

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.

> 
> 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.

> 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.

> 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.

Steven.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel