Arrow keys not working in VirtualBox

[Jiri Svoboda]

In VirtualBox arrow keys do not work in userspace (but they do work in kernel console).

xtkbd produces messages like "Unknown scancode: 2a" in the log.

The xtkbd driver recognizes 0xe0 0x2a 0xe0 0x37 as print screen.

VirtualBox sends 0xe0 0x2a 0xe0 0x48 when the up arrow key is pressed and 0xe0 0xc8 0xe0 0xaa when it is released. These sequences will be dropped as unrecognized by xtkbd.

[Jiri Svoboda]

Found this document ​https://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html that calls the sequence 0xe0 2a a "fake LShift". Upon quick reading I didn't quite get it, but it seems that it can appear quite liberally on some (old?) keyboards depending on the state of Shift and Lock keys and is required by some legacy software.

It is possible that VirtualBox implements this.

It is possible that we need to be able to cope with these sequences appearing, i.e. handle it in a smarter way than currently.

[Jiri Svoboda]

I've looked at the scancodes, as they are generated by Qemu:

2a	Shift press
aa	Shift release
e0 48	Up Key press
e0 c8	Up Key release
45	Num Lock press
c5 fa fa	Num Lock release
48	Numeric keypad Up / 8 press
c8	Numeric keypad Up / 8 release
e0 2a e0 37	Print Screen press
e0 b7 e0 aa	Print Screen release
e1 1d 45 e1 9d c5	Pause press
nothing	Pause release

(all the above scancode sequences stay the same if shift is held)

e0 37	Print Screen press while holding shift
e0 b7	Print Screen release while holding shift

[Jiri Svoboda]

I tried the same in VirtualBox and we get the extra e0 2a on press and e0 aa on release not just with Print Screen, but also with all the block cursor keys: up, down, left, right, insert, delete, home, end, page up, page down.

[Jiri Svoboda]

It looks like xtkbd gets a few things incorrect.

It will translate e1 1d 45 e1 9d c5 into Pause press. But that's wrong. It's really a press and release, just that the keyboard sends the release immediately. This way the virtual PRESS key is stuck depressed forever.

It will translate e0 2a e0 37 as Print Screen, but it will not recognize e0 37 as Shift + Print Screen.

It will also not recognize the scan codes for other block keys if they are combined with the 'Fake LShift'.

Here are the possible scancode sequences for the Up key, for example:

e0 48	Up key (Qemu, No fake LShift)
2a e0 48	Shift + Up (Qemu/VBox, No fake Lshift)
e0 2a e0 48	Up Key (VBox, Fake LShift)

I think the fake lshift is designed for software that does not recognize e0 extended codes. With this the Up key would be recognized as Shift + Numeric 8/Up.

Software that understands e0 codes can safely ignore this sequence (it does not change the meaning of the key press or release).

[Jiri Svoboda]

Fixed in changeset ​9e9d9bc60978e9063a54b74c9301b5001d74660f.