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.
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).
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
(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
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.
(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
(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
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.
(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.
(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.
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.
Hotfix process completed and documented here https://mojo.redhat.com/docs/DOC-1068251
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Missed 3.6.5, moving to 3.6.6
(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.
(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?
The customer confirmed all the bugs can be fixed without ImmDisableIME(-1).
oVirt 4.0 Alpha has been released, moving to oVirt 4.0 Beta target.
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