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

[Xen-devel] [PATCH 0 of 2] Fix keymap handling for vnc console

To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH 0 of 2] Fix keymap handling for vnc console
From: John Haxby <john.haxby@xxxxxxxxxx>
Date: Fri, 14 Nov 2008 17:31:20 +0000
Delivery-date: Fri, 14 Nov 2008 09:31:52 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.16 (X11/20080723)
[I've not posted a patch before so I expect I've got some things wrong. But I'm willing to re-post until I get it right!]


This following patches change the keymap handling code to better deal with non-English keyboards. In particular:

* The old code implicitly assumed that there was a 1-1 mapping between keysyms and scancodes. Unfortunately, this is often not the case. For example, on an UK keyboard, "@" can be generated from a shift sequence (the penultimate "small" key in the middle row) and by typing AltGr-q,

* Some keymaps are quite wrong: for example the Turkish AltGr-b was defined to be apostrophe. This conspired with the previous problem to make shift-2 result in a "B" instead of an apostrophe.

* Many symbols used in the keymaps were not defined and several keymaps were incomplete resulting in sequences that sent no scancode to the guest OS.

These two patches attempt to rectify these problems.

To find the scancode for a given keysym, the code looks in the "right" map so that for example, on a UK keyboard "@" will generate a scancode of 0x28 or 0x10 depending on whether the shift sequence or the altgr sequence is used. If a keysym can't be found in the right map then the code will check the other maps and generate implicit shift and altgr presses and releases to match what it thinks the user should have pressed. (So, for example, if you're using a UK keyboard but qemu-dm is expecting a Turkish keyboard then the shift sequence to generate "@" doesn't exist so the shift key is implicitly released, the AltGR key implicitly pressed and the 0x10 scancode sent -- this has the effect that keyboards will mostly do the "right" thing even if there is a mismatch between qemu-dm and the vnc client.)

Numlock handling is much as before although, so far as I can tell, Numlock defaults to "off" instead of "on" at boot time. However, there is a problem that if software in the guest changes the numlock state, the qemu-dm vnc server doesn't know this and the numlock state can become inverted.

The capslock key is ignored in favour of sending implcit shift-press shift-release sequences as recommended in the VNC protocol description.

The second patch corrects many of the existing keymap definitions so that they match the XKB definitions. The maps I have left alone I am unsure of as I'm not sure, from the names, what the corresponding xkb settings are. However, the ones I am sure of are now, I think, complete so that provided the vnc client and qemu-dm keymaps match it doesn't matter what the guest OS uses as its keymap (because it will get the correct scancodes).

So far as I can tell, for a given keyboard, if a sequence produces a given symbol on Windows then it will do the same under X. The reverse doesn't appear to be true: for example, shift-altgr-Q often gives Greek_OMEGA under X but does nothing in Windows.

If anyone is interested I have two (Linux specific) programs that can be used to generate and test keymap files.

The patches are against the xen-3.3-testing tree and relative to tools/ioemu-remote which is under git control rather than mercurial.


jch

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

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