Bug 844555 - RFE: new IME switcher prevents to send the key events to kvm
Summary: RFE: new IME switcher prevents to send the key events to kvm
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: libXi
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 908147 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-31 04:51 UTC by Akira TAGOH
Modified: 2017-12-19 01:01 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:


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

Description Akira TAGOH 2012-07-31 04:51:04 UTC
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 09:41:06 UTC
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 14:16:14 UTC
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-10 01:35:20 UTC
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-10 02:15:36 UTC
(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-10 02:32:52 UTC
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-10 02:47:54 UTC
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-10 03:02:20 UTC
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 10:43:16 UTC
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-08 00:59:41 UTC
*** Bug 908147 has been marked as a duplicate of this bug. ***

Comment 10 fujiwara 2013-02-08 01:03:22 UTC
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 09:18:03 UTC
Created attachment 835694 [details]
test case to reproduce the problem

Attached the simple test program.

Comment 12 fujiwara 2013-12-12 09:25:29 UTC
(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 09:34:23 UTC
Actually ibus uses gdk and probably I think gdk calls XISelectEvents() for the root window.

Comment 14 fujiwara 2013-12-12 10:01:45 UTC
Created attachment 835710 [details]
test case with gdk

Attached test case using gdk.

Comment 15 fujiwara 2015-09-15 06:08:25 UTC
I think this is fixed when the host is RHEL7.

Comment 16 Peter Hutterer 2017-12-19 01:01:44 UTC
just found this one while trawling through my open bugs - is this still an issue?


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