xen/altgr_2.patch
Charles Arnold 08a77ed8c4 - fate#310510 - fix xenpaging
xenpaging.tools_xenpaging_cleanup.patch

- fate#310510 - fix xenpaging
  xenpaging.mem_event_check_ring-free_requests.patch

- install /etc/xen/examples/xentrace_formats.txt to get human readable
  tracedata if xenalyze is not used

- fate#310510 - fix xenpaging
  xenpaging.autostart_delay.patch
  xenpaging.blacklist.patch
  xenpaging.MRU_SIZE.patch
  remove xenpaging.hacks.patch, realmode works

- Upstream patches from Jan including fixes for the following bugs
  bnc#583568 - Xen kernel is not booting
  bnc#615206 - Xen kernel fails to boot with IO-APIC problem
  bnc#640773 - Xen kernel crashing right after grub
  bnc#643477 - issues with PCI hotplug/hotunplug to Xen driver domain
  22223-vtd-igd-workaround.patch
  22222-x86-timer-extint.patch
  22214-x86-msr-misc-enable.patch
  22213-x86-xsave-cpuid-check.patch
  22194-tmem-check-pv-mfn.patch
  22177-i386-irq-safe-map_domain_page.patch
  22175-x86-irq-enter-exit.patch
  22174-x86-pmtimer-accuracy.patch
  22160-Intel-C6-EOI.patch

OBS-URL: https://build.opensuse.org/package/show/Virtualization/xen?expand=0&rev=76
2010-10-20 21:00:35 +00:00

57 lines
2.0 KiB
Diff

When access domU from Windows VNC client, spanish keyboard altgr key
doesn't work. According to log info, we found that the keycodes passed
from vncclient to qemu vncserver have something wrong. When altgr and "2"
pressed, keycodes vncserver receives are:
ALT_R down,
CTRL_L down,
CTRL_L up,
ATL_R up,
"2" down,
"2" up,
...
Since when send "2" down, there is no altgr modifier, the char displayed
on screen will be "2" but not "@".
To solve this problem, there is another patch applied by upstream which
sends an additional altgr modifier before "2" down in the above case.
It works well when domU is windows, but on sles10 sp3 domU, sometimes it
display "@" and sometimes it still displays "2", especially when press
altgr+2 continuously.
For the sles10 sp3 domU problem, maybe because there are two many alt_r (same
keycode as altgr on "es") up and down events and the domU OS couldn't handle
it well.
To furtherly solve this problem, I write this patch, when vncserver
is "es" and receives a alt_r keysym (this is already abnormal since "es" has
no alt_r), then treat the alt_r as alt_l. This can avoid too many altgr
keycodes up and down events and make sure the intentionally added altgr keycode can take effect.
Signed-off by Chunyan Liu (cyliu@novell.com)
diff -r a108300bd904 tools/ioemu-qemu-xen/vnc.c
--- a/tools/ioemu-qemu-xen/vnc.c Mon Sep 27 21:20:36 2010 +0800
+++ b/tools/ioemu-qemu-xen/vnc.c Wed Sep 29 01:55:55 2010 +0800
@@ -1279,11 +1279,9 @@
kbd_put_keycode(0xe0);
if (down){
kbd_put_keycode(0xb8 & 0x7f);
- vs->modifiers_state[0xb8] = 1;
}
else {
kbd_put_keycode(0xb8 | 0x80);
- vs->modifiers_state[0xb8] = 0;
}
}
@@ -1310,6 +1308,9 @@
shift_keys = vs->modifiers_state[0x2a] | vs->modifiers_state[0x36];
altgr_keys = vs->modifiers_state[0xb8];
+ if ( !strcmp(keyboard_layout,"es") && sym == 0xffea )
+ sym = 0xffe9;
+
keycode = keysym2scancode(vs->kbd_layout, sym & 0xFFFF);
if (keycode == 0) {
fprintf(stderr, "Key lost : keysym=0x%x(%d)\n", sym, sym);