A couple of keyboard event issues (was Re: [Vm-dev] [Windows cog
vm] [Keyboard events related] about keycode mapping)
juan at jvuletich.org
Fri Jan 27 01:42:43 UTC 2012
This is actually sort of unrelated, but I'm answering to this thread
just because this is also about how VMs report keystrokes in different
platforms. There are 2 things really don't like. It would be great to
have these fixed on the official VMs.
On the mac, when control or command are pressed, for any keystroke the
unshifted code is returned, even if shift is pressed. For instance,
let's assume an US keyboard. So, [shift]+[,] generates $< and
[shift]+[.] generates $>. If you run 'Sensor kbdTest' and press
[shift]+[,] you correctly get $<, but if you press [control]+[shift]+[,]
or [command]+[shift]+[,] you get $,. This is bad, because to detect
[command]+[<] or [control]+[<] you need to write code that not only
needs to know about the platform, but also about the keyboard layout, as
in many layouts $< is not generated by doing [shift]+[,], but by some
other combination. The same happens with most non-alphabetic keys, that
usually differ in different keyboard layouts.
There is a completely separated issue, and it happens both in Windows
and Mac. Here, [ctrl] + [an alphabetic key] substracts 64 from the code.
So, [ctrl]+[c] generates code 3. This is consistent with the traditional
meaning of the ctrl key (in dumb terminals and DOS), but it makes
impossible for the image to tell (for example) between [ctrl]+[Enter]
and [ctrl]+[m]. The image might want to use these keystrokes for
different things, so it would be much better not to substract 64 in the
VM and let the image handle it. I know it could be done by handling key
down and key up events, but this would also require code that is not
only platform dependent but also needs to know the mapping between key
codes and characters in each platform.
In general, I think that [control], [command] and [alt/option] should
not affect the character code of a keystroke, they should only set the
appropriate flag so the image can decide what to do with them. This is
completely different for [shift], as [shift] does indeed modify the
I haven't tested on Linux or other platforms, but things like these
could also happen.
Fixing these would enable a few simplifications in the image (at least
in Cuis) and also ease consistent behavior in different platforms. It
would also enable the use of some keystroke combinations involving
[command] and/or [control] that are problematic today.
More information about the Vm-dev