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.
Thanks
Pat
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home