[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.