[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. Thanks Pat _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |