[virt-tools-list] [Spice-devel] [PATCH] Disable IME to allow receiving all keys

Takao Fujiwara tfujiwar at redhat.com
Fri Apr 22 03:57:44 UTC 2016

On 04/21/16 19:45, Frediano Ziglio-san wrote:
>> On 04/21/16 01:17, Frediano Ziglio-san wrote:
>>>> On Wed, Apr 20, 2016 at 05:37:52PM +0900, Takao Fujiwara wrote:
>>>>> My understanding is, Virt-Viewer with ImmDisableIME(-1) can send key
>>>>> events even if the title bar is focused when IME is enabled.
>>>>> I attached the screenshot of the problem when ImmDisableIME(-1) is not
>>>>> applied.
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1311858#c42
>>>>> But spice-gtk can receives all the key events and if ImmDisableIME(-1) is
>>>>> applied, users cannot switch IMEs during running Virt-Viewer.
>>>>> I tested native client with Internet Explorer 10 in Windows 7 and I
>>>>> couldn't see any other differences when ImmDisableIME(-1) is applied.
>>>> This patch was needed for
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1297640
>>>> Setup was Windows client connecting to a Windows VM.
>>>> Without this patch, when remote-viewer is focused and the user is
>>>> interacting with the VM, it was not possible to press the
>>>> Zenkaku_Hankaku in order to switch input method within the VM.
>>>> Are you saying this is not needed, and that the situation I describe is
>>>> working
>>>> even without calling ImmDisableIME?
>>>> Christophe
>>> >From the subject looks like multiple keys (not specified) are not
>>> working, one is Zenkaku_Hankaku. Can we have a list of not working
>>> keys?
>> spice-gtk can receives Zenkaku_Hankaku events without the patch of
>> ImmDisableIME(-1).
> I asked to the reported which other key are not working.
>> I didn't find any problems without ImmDisableIME(-1) with the native client
>> from Internet Explorer 10 in Windows 7 and either MS-IME or MS Office IME.
> Why the version of Interner Explorer is important ?

I explained my environment exactly in case I missed something.
I guess ImmDisableIME(-1) is not needed for Windows 7 or higher.

>>> In this case the problem is different as the key is managed by Windows
>>> and not sent to application.
>>> I also noted that an issue happen when you press the title of the
>>> remote-viewer window and continue using the keyboard. In this case
>>> when you are in Japanese mode you don't receive keys events but a
>>> small window is opened where characters are typed.
>>> Do we want to have this behavior?
>> I think this is a specification of Windows and users don't mind the issue.
>> E.g. users can send IME events to the title bar of explorer.exe
> I was referring to the title bar of remote-viewer.
> Why is important the title bar of explorer.exe?

I mean receiving IME event in the title bar would be the expected result and we often see that behavior.
explorer's window pane does not have input fields but IME events can be sent to the title bar.

>> I think the customer real issue is MapVirtualKey() in spice-gtk and I guess
>> bug 1297640 didn't describe the accurate problem.
> I'd like to keep the patch in till we understand all the requirements
> and problems. Beside the language bar in the taskbar hidden (which IMHO
> is a Microsoft bug) I can't see other regression and the patch fix some
> other issues.

OK, I also asked to test the binary without ImmDisableIME but with patched MapVirtualKey().
Currently the side engineer replies the position opinion without ImmDisableIME and I hope I will get a feedback from the customer who is the same 
customer referred by bug 1297640.

>> I also think showing keyboard status on Windows task bar is useful for the
>> users.
> Yes, we should consider this. I'll open a bug, we should try addressing
> this.

Probably I think it's not a bug but a specification if you use ImmDisableIME.
It would be great if you could get a reply from a Microsoft engineer but I'd like to think refactoring codes can be considered later since the 
customer wish the fix urgently.
I also think it's better not to backported to the downstream if the customer does not need ImmDisableIME,


>> Thanks,
>> Fujiwara
> Frediano

More information about the virt-tools-list mailing list