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

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

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

Steven Smith wrote:
>> Steven Smith wrote:
>> [...]
>>>> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
>>>> +++ b/tools/xenfb/keymapping.c	Sat Sep 02 15:19:25 2006 -0400
>>>> @@ -0,0 +1,141 @@
>>>> +#include <stdint.h>
>>>> +#include <gdk/gdkkeysyms.h>
>>>> +#include <linux/input.h>
>>>> +
>>>> +uint32_t gdk_linux_mapping[0x10000] = {
>>>> +	[GDK_a] = KEY_A,
>>> This is kind of ugly.  Is there any chance it could be autogenerated?
>>> Also, where did 0x10000 come from?
>>>
>>> Also, depending on GTK just for the keymap table is a real pain.  Or
>>> is it already required for libvncserver?
>>>
>> For the VNC part, as it depends on libvncserver, it should use
>> /usr/include/rfb/keysym.h:
>>
>> +uint32_t gdk_linux_mapping[0x10000] = {
>> +	[XK_a] = KEY_A,
> Yes, you're right.  The dependency on GTK is unimportant, but
> libvncserver thinks it's generating X keysyms rather than GDK keys, so
> XK_* is the correct thing to use, I think.

Thanks

>> 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'.
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"...)

And how do you manage this one:

http://jcmc.indiana.edu/vol9/issue1/Japanese_Keyboard.gif

2- GDK scancode based:

* keymap is keymap of the frontend
* frontend knows how to translate ALL scancodes to a symbols.

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

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

> 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