Yoshinori Takahashi, Does this problem only happen with one specific keyboard model? Which one? When did you start noticing these issues? What's the workaround found by the user? Please, apart from your answers to the questions above, I would like to ask you to provide the remote-viewer log. For doing this, you'll need to: 1) Download debug-helper binary and place it where remote-viewer.exe resides. You can get the binary from: http://fidencio.fedorapeople.org/debug-helper.exe 2) Download gdb binary and place it where remote-viewer.exe resides. You can get the binary from: http://fidencio.fedorapeople.org/gdb.exe 3) On RHEV-M Portal, choose to use the "Native client". 4) Click in "Console" and save the vv-file 5) Open a Cmd 6) Go where remote-viewer.exe resides and run: debug-helper remote-viewer.exe vv-file You should see a Cmd window running gdb that will print stdout/stderr of remote-viewer.exe. Copy the whole output from there and attach to this bug report. Please, keep in mind that it will generate a really big amount of debug. So, try to do the minimum interaction possible for providing us the logs for this specific bug and give us a detailed step-by-step about what you did when getting the logs. Also, if you have an easy access to a bare metal Linux machine, I'd be really interested in getting the scancode of these problematic keys.
All these bugs are quite confusing. First: how virt-viewer/remote-viewer should work: send raw key to remote machine. No IME should be involved. The expected behavior of other client applications does not matter, the fact that client is connecting from a Windows machine or Linux or Mac should not change the expected behavior. Second: what is the guest configuration? This is the behavior the customer should expect, no matter what client is using. What the behavior of RHEL-7 set with Japanese pressing Alt-CapsLock? Better to test with physical (bare metal) machine, if not possible try with Qemu locals (SDL/GTK/others) or if not possible remotes (VNC/Spice) but better first options.
Probably I think this is not relative with IME and Alt key. Client: English (US) keyboard on Windows 7 Japanese edition Virtual Host: Only US keyboard on RHEL 7 GNOME When I type CapsLock, The lock is ON but when I type CapsLock again, the lock cannot be OFF.
See https://bugzilla.redhat.com/show_bug.cgi?id=1311804#c14 for reason why caps lock have problems with Japanese keyboards.
No, it's IMHO a client problem, not a guest one.
Does the patch work for the customer ?
Also, can we have the sources or the commit id (the hash) or the sources?
The ImmDisableIME is not necessary only if you have the grab of the keyboard. This as the windows hook which is installed when you have the keyboard grabbed receives the messages before IME change them. Try to click on the title, keep mouse there and press some keys, they won't work if IME is enabled.
Created attachment 1147585 [details] Screenshot without ImmDisableIME (In reply to Frediano Ziglio from comment #41) > The ImmDisableIME is not necessary only if you have the grab of the keyboard. > This as the windows hook which is installed when you have the keyboard > grabbed receives the messages before IME change them. Try to click on the > title, keep mouse there and press some keys, they won't work if IME is > enabled. My understanding is you mean the problem with the attaching screenshot, it cannot send the key events if the local IME enables Hiragana. I think it may be vice-versa. ImmDisableIME always can send the key events. No ImmDisableIME can show the keyboard status and users can change it. I'd like to ask the users which is preferred.
The customers verified the reported bugs are fixed with the test binary which were built from virt-viewer 0.6.0-34 with the patches in comment #43. I think the bug 1311820, bug 1311858 and bug 1311804 are fixed and bug 1297640 is duplicated of bug 1311820. Could you commit the patches in mingw-spice-gtk? The customer wishes the signed virt-viewer.msi asap.
(In reply to fujiwara from comment #44) > The customers verified the reported bugs are fixed with the test binary > which were built from virt-viewer 0.6.0-34 with the patches in comment #43. > I think the bug 1311820, bug 1311858 and bug 1311804 are fixed and bug > 1297640 is duplicated of bug 1311820. > > Could you commit the patches in mingw-spice-gtk? > The customer wishes the signed virt-viewer.msi asap.
(In reply to Fabiano Fidêncio from comment #45) > (In reply to fujiwara from comment #44) > > The customers verified the reported bugs are fixed with the test binary > > which were built from virt-viewer 0.6.0-34 with the patches in comment #43. > > I think the bug 1311820, bug 1311858 and bug 1311804 are fixed and bug > > 1297640 is duplicated of bug 1311820. > > > > Could you commit the patches in mingw-spice-gtk? > > The customer wishes the signed virt-viewer.msi asap. Why did you set rhevm-3.6.0? I think that way is not tested and it can fix my patch1 and patch3 but patch2 is still needed. I'd think applying my patch1 and patch2 can avoi any regressions.
oVirt 4.0 Alpha has been released, moving to oVirt 4.0 Beta target.
Sorry, was moved to MODIFIED by mistake.
Ouch, no, it was right. :-\
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