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: Anthony Liguori <aliguori@xxxxxxxxxxxxx>
Date: Fri, 08 Sep 2006 09:26:38 -0400
Cc: Laurent Vivier <Laurent.Vivier@xxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Markus Armbruster <armbru@xxxxxxxxxx>, sos22@xxxxxxxxxxxxx, Jeremy Katz <katzj@xxxxxxxxxx>
Delivery-date: Fri, 08 Sep 2006 09:52:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060907083848.GA3078@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>
References: <20060904090150.GC4812@xxxxxxxxx> <44FC224D.3090300@xxxxxxxx> <20060906091505.GD3257@xxxxxxxxx> <44FEB3DE.5070502@xxxxxxxx> <20060906171006.GA5306@xxxxxxxxx> <44FFCAC0.6060809@xxxxxxxx> <20060907083848.GA3078@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20060728)
Steven Smith wrote:
First: I now agree with you that scancodes are a better choice than
keysyms, and that I was wrong initially.

The problem with scancodes is that you cannot always get scancodes from the viewer. You can get scancodes from SDL but you can only get keysyms from VNC. We would have to map VNC keysyms (which are just Xk keysyms) to scancodes?

I'm a bit surprised here. If we generate a KEY_Q event in Linux that may show up as a KEY_A key? There are keysyms for all the extended keys I thought.


Anthony Liguori

  However, scancodes have
their own problems, and I'd like to make sure they're understood
before we go too far down this path.

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.
What happens if you connect vncviewer from a machine with a US
keyboard, then disconnect, and then reconnect from a machine with a
French keyboard?

It'd be nice if, from both machines, pressing the key labelled 'w' on
the keyboard resulted in a 'w' being sent to whatever application is
reading from the keyboard at the time.

A desktop like GNOME can manage that too...
Most Gnome apps care more about keysyms than scancodes, though, so
they'll just pick up whatever keymap is set with xmodmap.

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:


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.
Ack, sorry, not awake enough.

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 ?
Well, if the backend is attached to a French keyboard and the frontend
has a US keymap loaded.  When the user presses 'a', scancode 16 (say)
will be sent, and the frontend will then run that through its keymap
and get a 'q'.  It'd be good if pressing 'a' led to an 'a' appearing
on the screen.

Given that the backend knows exactly what each scancode is supposed to
map to, we should in principle be able to avoid this sort of problem.
It's just a matter of connecting everything up correctly. :)


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>