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

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

[John Haxby]

[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

Re: [PATCH 0 of 2] Fix keymap handling for vnc console

[Pat Campbell]

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@lists.xensource.com
> 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.

Thanks

Pat

Re: [PATCH 0 of 2] Fix keymap handling for vnc console

[John Haxby]

Pat Campbell wrote:
> 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. 
>
>   
Yes, the changes are reasonably independent although one shouldn't use 
the updated keymaps without the corresponding keymap/scancode handling 
because duplicate keysyms cause problems with the current code.

> 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                 
>   
Those keysyms are indeed present in my patch; the iso-level3-switch 
change is already part of the xen code.

> (vnc_keysym.h patch)
>   [Qemu-devel] Wrong keyboard mapping for Belgian keyboard  (bug report)
>
>   
That's a familiar looking bug report.   The problem described there is 
the problem with duplicate keysyms in the keymap which the original code 
completely failed to address.

I'll try to assemble a similar patch to this one and send it up to 
qemu-devel.
> I would be interested in your two programs.
>
>   
I'll post those shortly as well.

jch