John Haxby
2008-Nov-14 17:31 UTC
[Xen-devel] [PATCH 0 of 2] Fix keymap handling for vnc console
[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
Pat Campbell
2008-Nov-18 15:56 UTC
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@lists.xensource.com > http://lists.xensource.com/xen-develAre 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@lists.xensource.com http://lists.xensource.com/xen-devel
John Haxby
2008-Dec-01 14:42 UTC
Re: [Xen-devel] [PATCH 0 of 2] Fix keymap handling for vnc console
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel