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/
Home Products Support Community News


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: Thu, 07 Sep 2006 09:31:12 +0200
Cc: Jeremy Katz <katzj@xxxxxxxxxx>, aliguori <aliguori@xxxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, sos22@xxxxxxxxxxxxx, Markus Armbruster <armbru@xxxxxxxxxx>
Delivery-date: Thu, 07 Sep 2006 00:31:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060906171006.GA5306@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> <44FEB3DE.5070502@xxxxxxxx> <20060906171006.GA5306@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20060420)
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.


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

         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
<Prev in Thread] Current Thread [Next in Thread>