Yoshinori Takahashi, So, your problem here is that Caps Lock state between client and guest are not synced. Is it? Please, apart from your answer to the questions above, I would like to ask you to provide virt-viewer logs. 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.
It seems this is duplicated of bug 1311858. If you wish to use Shift+Eisu_toggle, the workaround is to run 'setxkbmap -laout jp' whenever switch the keymaps in GNOME. If you wish to use CapsLock, the workaround is to run 'setxkbmap -layout us' whenever switch the keymaps in GNOME..
I think that the root cause of this is the way we handle caps locks (and locks in general). Basically we expect the locks to behave the same on client and on guest and if guest is not acting according we emulate key presses to try to force the sync. However this causes problem if the locks key behave not as expected. With Japanese keyboards the caps lock handle either change from alphanumeric to Japanese or the normal caps lock behavior (according to system settings and shift/control/alt combinations). Adding spurious keys cause weird behavior. Try to use an English Linux system to connect to a Japanese machine and you'll get similar problems.
People said this problem is fixed in 0.6.0-36.
oVirt 4.0 Alpha has been released, moving to oVirt 4.0 Beta target.
Seems virt-viewer 2.0-129 has a change against 0.6.0. If Windows client configures 'jp' keyboard, either Eisu_toggle on 'jp' keyboard or Caps_Lock on 'us' keyboard do not lock the alphabet cases in RHEL desktop. If Windows client configures 'us' keyboard, either Eisu_toggle or Caps_Lock locks the alphabet cases in RHEL desktop. Do you know which patch affect this behavior? Almost CJK users would not change the keymaps so the change looks no problem but I think it can effect other users.
It's not clear he combination (client and guest) are you trying. We know that there is a synchronization problem with capslock key with mainly cause some extra keystroke to be sent which could cause this type of issues. The behavior change should (I cannot be sure without details on client/guest configurations) came mostly from the fact that eisu_toggle were not sent to guest.
OK, I see. Thanks. I have another question. The customer uses both native client and browser plugin. How can we install the browser plugin? The virt-viewer*.msi installs the native client only. My understanding is SpiceX*.cab has the browser plugin which is installed via Internet explorer. Can we replace the plugin in RHEVM portal server or install the plugin by manual? I'm also not sure if 2.0-129 cab file works with RHEVM 3.6.
(In reply to fujiwara from comment #32) > I have another question. > The customer uses both native client and browser plugin. > How can we install the browser plugin? > The virt-viewer*.msi installs the native client only. > > My understanding is SpiceX*.cab has the browser plugin which is installed > via Internet explorer. > Can we replace the plugin in RHEVM portal server or install the plugin by > manual? For RHEVM 3.6 you should be able to simply install the rhevm-spice-client-x??-cab-3.6-7.el6.noarch.rpm on the rhevm 3.6 server (and restart rhevm services). The new cab file is supposed to be automatically installed on the client the next time it tries to open a spice connection via a RHEV-M portal. > > I'm also not sure if 2.0-129 cab file works with RHEVM 3.6. It should work with RHEVM 3.6. mingw-virt-viewer-2.0-8.el7ev.1 ( == 2.0-129) is included in rhevm-spice-client 3.6-7. Please note that this specific bug is for RHEVM 4.0
Thank you for the reply. I didn't know it since I haven't set up the RHEVM server.
There were different causes for this issue: 1- keys not handled by spice client (keys not handled properly by application); 2- different keyboard configurations; 3- client IME settings; 4- modifiers behaviors. First 3 (1 is entirely fixed by a recent patch but with this bug description should not be affected) were solved and merged to oVirt 4 release. Problem 4 is still in progress and described more closely by https://bugzilla.redhat.com/show_bug.cgi?id=1337576.
Current version fix the issue and was released with last oVirt.