@@ -1893,7 +1893,22 @@ static void do_key_event(VncState *vs, int down, int keycode, int sym)
}
if (qemu_console_is_graphic(NULL)) {
- qemu_input_event_send_key_number(vs->vd->dcl.con, keycode, down);
+ int scancode = keysym2scancode(vs->vd->kbd_layout, sym);
+ if (scancode == (scancode & SCANCODE_KEYMASK)) {
+ qemu_input_event_send_key_number(vs->vd->dcl.con, keycode, down);
+ } else {
+ if (scancode & SCANCODE_SHIFT && !(vs->modifiers_state[0x2a] ||
+ vs->modifiers_state[0x36])) {
+ qemu_input_event_send_key_number(vs->vd->dcl.con, 0x2a, true);
+ qemu_input_event_send_key_delay(0);
+ }
+ qemu_input_event_send_key_number(vs->vd->dcl.con, keycode, down);
+ if (scancode & SCANCODE_SHIFT && !(vs->modifiers_state[0x2a] ||
+ vs->modifiers_state[0x36])) {
+ qemu_input_event_send_key_delay(0);
+ qemu_input_event_send_key_number(vs->vd->dcl.con, 0x2a, false);
+ }
+ }
} else {
bool numlock = vs->modifiers_state[0x45];
bool control = (vs->modifiers_state[0x1d] ||
v2: Replaced some parentheses I lost when preparing the patch for submission. If the keymap specifies the shift modifier for a keysym and that modifier isn't in effect, send a fake press/release for shift around the key event. Specifically, this resolves the issue of # producing a 3 when I press the # on my UK keyboard with a VM with a US keyboard. (FYI the UK # key is where the US @ key goes.) I think this is a legit change because the RFB protocol specification says that servers are expected to do this. It specifically highlights # as an example of where you'd need to do this! I wasn't sure whether to do this for all the modifiers - my use case doesn't call for it - so I didn't. Signed-off-by: Nathan Baum <n@p12a.org.uk> --- ui/vnc.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)