This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 844555 - RFE: new IME switcher prevents to send the key events to kvm
RFE: new IME switcher prevents to send the key events to kvm
Status: NEW
Product: Fedora
Classification: Fedora
Component: libXi (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
: Regression
: 908147 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-31 00:51 EDT by Akira TAGOH
Modified: 2015-09-15 02:08 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
test case to reproduce the problem (1.76 KB, text/plain)
2013-12-12 04:18 EST, fujiwara
no flags Details
test case with gdk (1.48 KB, text/plain)
2013-12-12 05:01 EST, fujiwara
no flags Details

  None (edit)
Description Akira TAGOH 2012-07-31 00:51:04 EDT
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:
Comment 1 Akira TAGOH 2012-08-06 05:41:06 EDT
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.
Comment 2 Peng Huang 2012-08-09 10:16:14 EDT
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.
Comment 3 Akira TAGOH 2012-08-09 21:35:20 EDT
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.
Comment 4 fujiwara 2012-08-09 22:15:36 EDT
(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.
Comment 5 fujiwara 2012-08-09 22:32:52 EDT
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.
Comment 6 Akira TAGOH 2012-08-09 22:47:54 EDT
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.
Comment 7 fujiwara 2012-08-09 23:02:20 EDT
But probably I think this problem cannot be fixed in ibus side if ibus uses the global XI2 keybinding.
Comment 8 fujiwara 2012-08-14 06:43:16 EDT
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.
Comment 9 fujiwara 2013-02-07 19:59:41 EST
*** Bug 908147 has been marked as a duplicate of this bug. ***
Comment 10 fujiwara 2013-02-07 20:03:22 EST
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.
Comment 11 fujiwara 2013-12-12 04:18:03 EST
Created attachment 835694 [details]
test case to reproduce the problem

Attached the simple test program.
Comment 12 fujiwara 2013-12-12 04:25:29 EST
(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.
Comment 13 fujiwara 2013-12-12 04:34:23 EST
Actually ibus uses gdk and probably I think gdk calls XISelectEvents() for the root window.
Comment 14 fujiwara 2013-12-12 05:01:45 EST
Created attachment 835710 [details]
test case with gdk

Attached test case using gdk.
Comment 15 fujiwara 2015-09-15 02:08:25 EDT
I think this is fixed when the host is RHEL7.

Note You need to log in before you can comment on or make changes to this bug.