Description of problem: With the latest version of ibus on f17, ibus can't be turned on on kvm. it works back when ibus on host machine is disabled. Version-Release number of selected component (if applicable): ibus-1.4.99.20120428-2.fc17.x86_64 How reproducible: always Steps to Reproduce: 1.run ibus on both host and guest 2.press ctrl+space on kvm 3. Actual results: the key events was ate on host. no IM activated on guest Expected results: should be turned on on kvm Additional info:
ctrl_L+alt_L on the guest window from virt-manager would be a workaround though, I'd say it's still a regression since it worked until ibus introduced new IME switcher.
Weird. I tried execute `qemu-kvm -cdrom Fedora-17-x86_64-Live-Desktop.iso -m 1024m` in fedora 17 host with upstream ibus. And the ibus works fine in both guest and host.
I have no idea how fedora's ibus and upstream's is different. the root cause is, IME switcher on host eats the key events during it appears.
(In reply to comment #2) > Weird. I tried execute `qemu-kvm -cdrom Fedora-17-x86_64-Live-Desktop.iso -m > 1024m` in fedora 17 host with upstream ibus. And the ibus works fine in both > guest and host. It's not the problem between upstream and downstream. I can reproduce the problem with upstream ibus + VirtualBox or vncviewer. I talked with upstream and it seems he don't think this is a bug but the expected behavior while the problem is not reproduced in ibus 1.4.
Probably I will close this issue as not a bug. It would be great if you could check the problem in f18 ibus. Note: you need to modify imsettings-start.desktop to enable gnome-settings-daemon's ibus.
Yes, it worked before. thus I'm saying it's a regression though. it's not a bug? definitely a bug. plus, it's not relevant to gnome integration. as I said, this happens with f17 guest on f17 host. I guess the root cause may be same to Bug#810211 from the technical POV. this issue happens no matter what guest is running, as long as the new IME switcher is available on host. I'd suggest to re-design the IME switcher again. it's quite buggy and has the problematic behavior with a lot of regressions.
But probably I think this problem cannot be fixed in ibus side if ibus uses the global XI2 keybinding.
I had some tests to call XIALlowEvents but I could not see any differences. It's a bit complicated situlation. Firstly Control+space is handled in XI2 and ibus activates a GTK window to switch ibus engines likes Alt+Tab window. So secondary the gtk window grabs key events. Now the keyevents are not forward to applications. What I did was: GdkDevice *device = gdk_event_get_device (event); Display *xdisplay = GDK_DISPLAY_XDISPLAY (gdk_display_get_default()); XIAllowEvents (xdisplay, gdk_x11_device_get_id (device), ReplayKeyboard, event.key.time); XFlush (xdisplay); Since the switcher UI will be moved from ibus panel to gnome-settings-daemon in Fedora 18, probably I will wait for that implementation in desktop team.
*** Bug 908147 has been marked as a duplicate of this bug. ***
The workaround is to set the different trigger keys between the parent desktop and the VM desktop. The ibus 1.5 trigger key is not the local key on client applications but the global key on the parent desktop so it won't be sent to the VM, vnc, rdesktop and so on.
Created attachment 835694 [details] test case to reproduce the problem Attached the simple test program.
(In reply to fujiwara from comment #11) > Created attachment 835694 [details] > test case to reproduce the problem > > Attached the simple test program. When this program runs in both host box and VM box, Ctrl+space event is always taken by host box. I'd like to send Ctrl+space into VM box but have no idea. Transferring to XI2 for the furthermore investigation.
Actually ibus uses gdk and probably I think gdk calls XISelectEvents() for the root window.
Created attachment 835710 [details] test case with gdk Attached test case using gdk.
I think this is fixed when the host is RHEL7.
just found this one while trawling through my open bugs - is this still an issue?