Local client keyboard layout shouldn't affect hardware scancode sent to guest, so that guest keyboard layout configuration can map it properly. Unfortunately, the Win32 GdkEventKey.hardware_keycode isn't a hardware scancode, but the Windows virtual-key code. We could modify Gdk to return the scancode (available in MSG.lParam or via global hook), but that would mean some Gdk breakage, or some unnecessary complexity. Instead, we can rely on MapVirtualKey(), which translates the vitual-key code into a scan code using current keyboard layout. This solves the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=871125 --- gtk/spice-widget.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/gtk/spice-widget.c b/gtk/spice-widget.c index 3febb66..0df610b 100644 --- a/gtk/spice-widget.c +++ b/gtk/spice-widget.c @@ -1001,6 +1001,12 @@ static gboolean key_event(GtkWidget *widget, GdkEventKey *key) scancode = vnc_display_keymap_gdk2xtkbd(d->keycode_map, d->keycode_maplen, key->hardware_keycode); +#ifdef WIN32 + /* MapVirtualKey doesn't return scancode with needed higher byte */ + scancode = MapVirtualKey(key->hardware_keycode, MAPVK_VK_TO_VSC) | + (scancode & 0xff00); +#endif + switch (key->type) { case GDK_KEY_PRESS: send_key(display, scancode, 1); -- 1.7.11.7 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel