Hi ----- Mensaje original ----- > On Tue, Oct 30, 2012 at 12:20:09PM +0100, Marc-André Lureau 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. > > Hmm, I'm a little confused about this. The keyboard map we're using > should already be using Windows virtual-key codes as the source map, > so doing the right thing here. What you're doing here is just > skipping > our keyboard maps competely which is not right IMHO. > > I think the right thing is to just fix whatever mistake we have in > our keyboard maps, not avoid them. My understanding is that we map GDK GdkEventKey.hardware_keycode code to XT scan code. Under Windows, GdkEventKey.hardware_keycode is the virtual-key code, which is already translated to local keyboard layout. It's not possible to get the lowlevel hardware scan code from win32 Gdk, so I don't see how we can solve this with our map. Either we break Gdk to return lowlevel scancode or we use a global hook, in the end, we don't need our map table. Or we build a reverse kbd layout table (which might be changed dynamically) Thanks for the help! _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel