A couple of keyboard event issues (was Re: [Vm-dev] [Windows cog vm] [Keyboard events related] about keycode mapping)

Juan Vuletich juan at jvuletich.org
Fri Jan 27 01:42:43 UTC 2012


Hi Folks,

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 
character generated.

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.

Thanks,
Juan Vuletich


More information about the Vm-dev mailing list