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

[Laurent Vivier <Laurent.Vivier@bull.net>]

[-- Attachment #1.1: Type: text/plain, Size: 4390 bytes --]

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@bull.net
         Bull, Architect of an Open World (TM)
+----- "Any sufficiently advanced technology is ----+
| indistinguishable from magic." - Arthur C. Clarke |


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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