WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Steven Smith <sos22-xen@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Paravirt framebuffer backend tools [2/5]
From: Laurent Vivier <Laurent.Vivier@xxxxxxxx>
Date: Wed, 06 Sep 2006 13:41:18 +0200
Cc: Jeremy Katz <katzj@xxxxxxxxxx>, aliguori <aliguori@xxxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, sos22@xxxxxxxxxxxxx, Markus Armbruster <armbru@xxxxxxxxxx>
Delivery-date: Wed, 06 Sep 2006 04:42:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060906091505.GD3257@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Bull S.A.S.
References: <20060904090150.GC4812@xxxxxxxxx> <44FC224D.3090300@xxxxxxxx> <20060906091505.GD3257@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.2 (X11/20060420)
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@xxxxxxxx
         Bull, Architect of an Open World (TM)
+----- "Any sufficiently advanced technology is ----+
| indistinguishable from magic." - Arthur C. Clarke |

Attachment: signature.asc
Description: OpenPGP digital signature

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