8547e28bd5
23233-hvm-cr-access.patch 23234-svm-decode-assist-base.patch 23235-svm-decode-assist-crs.patch 23236-svm-decode-assist-invlpg.patch 23238-svm-decode-assist-insn-fetch.patch 23303-cpufreq-misc.patch 23304-amd-oprofile-strings.patch 23305-amd-fam15-xenoprof.patch 23306-amd-fam15-vpmu.patch 23334-amd-fam12+14-vpmu.patch 23338-vtd-force-intremap.patch - fate#310957 - Update to Xen 4.1.1-rc1 c/s 23064 - xentrace: dynamic tracebuffer allocation xen-unstable.xentrace.dynamic_tbuf.patch xen-unstable.xentrace.empty_t_info_pages.patch xen-unstable.xentrace.verbose.patch xen-unstable.xentrace.no_gdprintk.patch xen-unstable.xentrace.comments.patch xen-unstable.xentrace.printk_prefix.patch xen-unstable.xentrace.remove_debug_printk.patch xen-unstable.xentrace.t_info_pages-formula.patch xen-unstable.xentrace.register_cpu_notifier-boot_time.patch xen-unstable.xentrace.t_info_page-overflow.patch xen-unstable.xentrace.t_info_first_offset.patch xen-unstable.xentrace.data_size__read_mostly.patch xen-unstable.xentrace.__insert_record-dst-type.patch OBS-URL: https://build.opensuse.org/package/show/Virtualization/xen?expand=0&rev=124
46 lines
1.9 KiB
Diff
46 lines
1.9 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)
|
|
|
|
Index: xen-4.1.1-testing/tools/ioemu-qemu-xen/vnc.c
|
|
===================================================================
|
|
--- xen-4.1.1-testing.orig/tools/ioemu-qemu-xen/vnc.c
|
|
+++ xen-4.1.1-testing/tools/ioemu-qemu-xen/vnc.c
|
|
@@ -1308,6 +1308,9 @@ static void do_key_event(VncState *vs, i
|
|
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);
|