Bug 1297640 - Remote-viewer application unable to send some keys due to IME not disabled
Remote-viewer application unable to send some keys due to IME not disabled
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: mingw-virt-viewer (Show other bugs)
unspecified
Unspecified Windows
high Severity urgent
: ovirt-4.0.0-rc
: ---
Assigned To: Fabiano Fidêncio
SPICE QE bug list
: OtherQA, ZStream
Depends On: spice_japanese_keyboard
Blocks: 1332619
  Show dependency treegraph
 
Reported: 2016-01-12 00:20 EST by Ken Sugawara
Modified: 2016-12-08 02:30 EST (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, the Zenkaku_Hankaku key could not be passed to virtual machines from client machines running Japanese versions of Windows, as it was captured by Windows. This issues was resolved by disabling input method handling. The Zenkaku_Hankaku key can now be passed to virtual machines rather than being captured by Windows.
Story Points: ---
Clone Of:
: 1332619 (view as bug list)
Environment:
Last Closed: 2016-08-23 16:48:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Spice
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ken Sugawara 2016-01-12 00:20:55 EST
Description of problem:

On Japanese versions of Windows (I suspect the same happens on other Asian languages versions like Chinese and Korean), remote-viewer cannot send some keys, notably Zenkaku_Hankaku key which is used to toggle Japanese input mode on Windows, due to IME not disabled prior to start a session.

Because RHEV users are unable to input the Zenkaku_Hankaku key on remote-viewer session, they are not able to use the key to switch the ibus input source, to make the typing operation similar to Windows that they are used to.


Version-Release number of selected component (if applicable):
remote-viewer-0.6-34

How reproducible:
Always.


Steps to Reproduce:
1. Connect to RHEV-M User Portal using a Windows PC with a Japanese keyboard
2. Connect to a RHEL guest running in Japanese (locale = ja_JP)
3. Run xev, and with mouth focus on it, try pressing Zenkaku_Hankaku key.

Actual results:
Xev does not receive any event.

Expected results:
Xev receives events associated with the key stroke, one of which would be something similar to the following:

KeyRelease event, serial 33, synthetic NO, window 0x2a00001
    root 0x186, subw 0x2a00002, time 13428797, (37,50), root:(44,116)
    state 0x0, keycode 49 (keysym 0xff2a, Zenkaku_Hankaku), same_screen YES
    XLookupString gives 0 bytes:
    XFilterEvent returns: False




Additional info:

You can call immDisableIME() from your windows app to disable IME thus enabling remote-viewer to receive Zenkaku_Hankaku key code. See: 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318535(v=vs.85).aspx

This is an urgent issue for a large-scale VDI customer in Japan (3000+ users). They use primarily Windows PCs to connect to RHEV guests, and they want the guests to be similar in terms of key input operations to the native Windows as much as possible. Using Zenkaku_Hankaku key to switch input modes between direct input and Kana-Kanji conversion mode is one of the most important requirement for them.
Comment 1 Ken Sugawara 2016-01-12 00:26:35 EST
Correction: Step 2 of "Steps to Reproduce" is unnecessary. It should reproduce as long as you run remote-viewer.exe on Japanese Windows with IME enabled (ie in Japanese input mode).
Comment 2 David Jaša 2016-01-14 06:46:40 EST
Ken, do you have a test environment where you could check current 3.6 build [1] so we're sure that 3.6 is also affected?

[1] https://brewweb.devel.redhat.com/buildinfo?buildID=471974
Comment 3 David Blechter 2016-01-14 07:58:08 EST
(In reply to David Jaša from comment #2)
> Ken, do you have a test environment where you could check current 3.6 build
> [1] so we're sure that 3.6 is also affected?
> 
> [1] https://brewweb.devel.redhat.com/buildinfo?buildID=471974

to late for 3.6
Comment 4 Red Hat Bugzilla Rules Engine 2016-01-14 07:58:10 EST
This bug is flagged for 3.6, yet the milestone is for 4.0 version, therefore the milestone has been reset.
Please set the correct milestone or add the flag.
Comment 6 David Blechter 2016-01-14 07:58:30 EST
(In reply to David Jaša from comment #2)
> Ken, do you have a test environment where you could check current 3.6 build
> [1] so we're sure that 3.6 is also affected?
> 
> [1] https://brewweb.devel.redhat.com/buildinfo?buildID=471974

too late for 3.6
Comment 7 Red Hat Bugzilla Rules Engine 2016-01-14 07:58:33 EST
This bug is flagged for 3.6, yet the milestone is for 4.0 version, therefore the milestone has been reset.
Please set the correct milestone or add the flag.
Comment 9 Ken Sugawara 2016-01-15 04:43:30 EST
(In reply to David Jaša from comment #2)
> Ken, do you have a test environment where you could check current 3.6 build
> [1] so we're sure that 3.6 is also affected?
> 
> [1] https://brewweb.devel.redhat.com/buildinfo?buildID=471974

No, I don't. And it will have to wait for the completion of current project...
I'm just too busy finishing up this project to do any investigation myself.
Sorry.

However, AFAICT the latest upstream version of virt-viewer (remote-viewer) doesn't call immDisableIME() anywhere, so I'm guessing any version is affected by this bug...

Ken
Comment 10 Christophe Fergeau 2016-01-15 08:16:27 EST
I've made a scratch build of the upstream version with an added call to ImmDisableIME(-1). Since I'm not sure what the Zenkaku_Hankaku key is nor if I have one on my keyboard, I don't know if I'll be successful in testing this.
If you get a chance to test https://koji.fedoraproject.org/koji/taskinfo?taskID=12561985 after your current project is done, it would be very helpful.
Comment 11 Ken Sugawara 2016-01-16 08:22:04 EST
(In reply to Christophe Fergeau from comment #10)
> I've made a scratch build of the upstream version with an added call to
> ImmDisableIME(-1). Since I'm not sure what the Zenkaku_Hankaku key is nor if
> I have one on my keyboard, I don't know if I'll be successful in testing
> this.
> If you get a chance to test
> https://koji.fedoraproject.org/koji/taskinfo?taskID=12561985 after your
> current project is done, it would be very helpful.

Thanks, Christophe. I will try it on Monday.
Comment 12 Ken Sugawara 2016-01-19 05:09:46 EST
(In reply to Ken Sugawara from comment #11)
> (In reply to Christophe Fergeau from comment #10)
> > I've made a scratch build of the upstream version with an added call to
> > ImmDisableIME(-1). Since I'm not sure what the Zenkaku_Hankaku key is nor if
> > I have one on my keyboard, I don't know if I'll be successful in testing
> > this.
> > If you get a chance to test
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=12561985 after your
> > current project is done, it would be very helpful.
> 
> Thanks, Christophe. I will try it on Monday.

Ok, here goes the status update.

The test binaries work well in an environment where IMM32 API is supported well.

It turns out that immDisableIME() call was part of the legacy IMM32 API, and the IMM32 API is phased out by the newer TSF 1.0 (Text Services Framework) API.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms629032(v=vs.85).aspx

Windows 8 or later only supports TSF 1.0, so, while the proposed patch works fine on Windows XP and up to Windows 7 (*), it won't work well on Windows 8 or later (unfortunately I don't have any of them to test on).

TSF 1.0 is supposed to be supported on Windows XP or later, so I now propose remote-viewer be modified to support this new input framework although I have no idea how to fix it cause I'm a pure UN*X guy. This is as much research as I can do on the subject by googling, etc.

* Windows 7 was transitional in terms of input services; TSF 1.0 was natively supported while it provided a half-baked IMM32 emulation support for older applications. Because IMM32 was still much more popular at the time of Win7's release than TSF 1.0, Microsoft later released the Office IME 2010 which had more robust IMM32 emulation. I tested the test binary on a Win7 PC with the Office IME 2010 installed.
Comment 13 Frediano Ziglio 2016-03-17 07:26:50 EDT
I tested with Windows 10 and looks like ImmDisableIME is not causing any issue on it. As this is the recommended way to disable IME I would apply this patch anyway. It will fix issues on Windows 7 having no regressions on later versions.
Comment 15 Frank DeLorey 2016-03-22 12:32:10 EDT
Hotfix process completed and documented here https://mojo.redhat.com/docs/DOC-1068251
Comment 21 Mike McCune 2016-03-28 19:26:37 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 22 Yaniv Kaul 2016-04-14 03:44:02 EDT
Missed 3.6.5, moving to 3.6.6
Comment 23 fujiwara 2016-04-18 22:56:39 EDT
(In reply to Ken Sugawara from comment #0)
> Description of problem:
> Additional info:
> 
> You can call immDisableIME() from your windows app to disable IME thus
> enabling remote-viewer to receive Zenkaku_Hankaku key code. See: 
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd318535(v=vs.85).
> aspx

I think your problem is not relative with ImmDisableIME().
You don't ask the problem with mouse click and spice-gtk receives Zenkaku_Hankakku events.
I expect my patch also fixes this bug.
Comment 24 Frediano Ziglio 2016-04-21 06:37:20 EDT
(In reply to Ken Sugawara from comment #0)
> Description of problem:
> 
> On Japanese versions of Windows (I suspect the same happens on other Asian
> languages versions like Chinese and Korean), remote-viewer cannot send some
> keys, notably Zenkaku_Hankaku key which is used to toggle Japanese input
> mode on Windows, due to IME not disabled prior to start a session.
> 

Which other key combination are not working?
Comment 25 fujiwara 2016-04-25 05:06:40 EDT
The customer confirmed all the bugs can be fixed without ImmDisableIME(-1).
Comment 27 Yaniv Lavi (Dary) 2016-05-09 06:58:28 EDT
oVirt 4.0 Alpha has been released, moving to oVirt 4.0 Beta target.
Comment 33 errata-xmlrpc 2016-08-23 16:48:05 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-1681.html

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