This patch solves keyboard layout issues on Windows. It doesn't seem to introduce regression. There is no better solution atm, I explained in previous mail that the original problem could be rooted in Gtk-Win32 backend, which doesn't pass hw scancode. Since we are using it for Windows build, I propose we apply it upstream too.
cheers
On Wed, Oct 31, 2012 at 4:51 PM, Marc-André Lureau <marcandre.lureau@xxxxxxxxx> wrote:
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
--
Marc-André Lureau
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel