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 0 of 2] Fix keymap handling for vnc console

To: John Haxby <john.haxby@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0 of 2] Fix keymap handling for vnc console
From: Pat Campbell <plc@xxxxxxxxxx>
Date: Tue, 18 Nov 2008 08:56:38 -0700
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 18 Nov 2008 07:58:37 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <491DB5E8.2050509@xxxxxxxxxx>
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>
References: <491DB5E8.2050509@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20070801)
John Haxby wrote:
> [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

Are the keymap files and vnc_keysym.h changes independent of the code
changes?   Not sure what others think but if they are independent then
there should be two distinct patch sets.  One for keysmaps and
vnc_keysym.h and another for the keysym/scancode handling. 

Although not as inclusive, I see some vnc_keysym.h changes have been
recently sent upstream to qemu-devel. Are you going to send a derivative
of this patch set upstream to qemu-devel? 
  [Qemu-devel] AltGr and dead keys with VNC                 
(vnc_keysym.h patch)
  [Qemu-devel] Wrong keyboard mapping for Belgian keyboard  (bug report)

I would be interested in your two programs.



Xen-devel mailing list

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