So both the client and the guest are running Windows 7?
Yoshinori Takahashi, I'm a bit lost here. I don't what's the user is trying to achieve by presing ALT key more than 10 seconds and simultaneously press "half/fulll" key. Could you explain what's the use case, what's the user is trying to achieve by doing this? What do you mean by "half/full" key combination? I'm not familiar with at all with this nomenclature. Also, does this problem only happen with one specific keyboard model? Which one? When did you start noticing these issues? 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.
Ok, I think I got the root cause of this problem. On Windows ALT-half/full for more than 10 seconds change the IME which cause WM_KEYDOWN and similar to use VK_PROCESSKEY as virtual key instead of normal ones causing keyboard not working at all. This is fixed mainly with IME disabling in Windows 7 and also by my hacky patch for all Windows versions (however my patch has potentially many other issues).
0.6.0-35 has this issue as the scancode is lost in Gdk transformations. 0.6.0-36 has this issue as Windows reverse key press/release so Linux this the key is always pressed. If desktop freeze looks like a desktop problem. I tested and looks like if you just press that key and hold Gnome desktop freeze for a while. You can reproduce even on a bare metal machine. Set keyboard to Japanese, open htop, press the key and htop will freeze till you release the key!
Created attachment 1137645 [details] xev log when press Zenkaku_Hankaku key (In reply to Frediano Ziglio from comment #37) > If desktop freeze looks like a desktop problem. I tested and looks like if > you just press that key and hold Gnome desktop freeze for a while. > You can reproduce even on a bare metal machine. Set keyboard to Japanese, > open htop, press the key and htop will freeze till you release the key! I don't think Zenkaku_Hankaku key itself does not freeze but that unlimited key events cause the desktop freeze so it's a virt-viewer bug. Attached the xev log. Did you reproduce this problem with 0.6.0-36? > 0.6.0-36 has this issue as Windows reverse key press/release so Linux this > the key is always pressed. Do you have a patch to fix this?
(In reply to fujiwara from comment #38) > Created attachment 1137645 [details] > xev log when press Zenkaku_Hankaku key > > (In reply to Frediano Ziglio from comment #37) > > If desktop freeze looks like a desktop problem. I tested and looks like if > > you just press that key and hold Gnome desktop freeze for a while. > > You can reproduce even on a bare metal machine. Set keyboard to Japanese, > > open htop, press the key and htop will freeze till you release the key! > > I don't think Zenkaku_Hankaku key itself does not freeze but that unlimited > key events cause the desktop freeze so it's a virt-viewer bug. Sorry typo. I don't think Zenkaku_Hankaku key itself freeze but that unlimited key events cause the desktop freeze so it's a virt-viewer bug.
(In reply to fujiwara from comment #39) > (In reply to fujiwara from comment #38) > > Created attachment 1137645 [details] > > xev log when press Zenkaku_Hankaku key > > > > (In reply to Frediano Ziglio from comment #37) > > > If desktop freeze looks like a desktop problem. I tested and looks like if > > > you just press that key and hold Gnome desktop freeze for a while. > > > You can reproduce even on a bare metal machine. Set keyboard to Japanese, > > > open htop, press the key and htop will freeze till you release the key! > > > > I don't think Zenkaku_Hankaku key itself does not freeze but that unlimited > > key events cause the desktop freeze so it's a virt-viewer bug. > > Sorry typo. > I don't think Zenkaku_Hankaku key itself freeze but that unlimited key > events cause the desktop freeze so it's a virt-viewer bug. It happens on bare metal too and here there is no virt-viewer.
(In reply to Frediano Ziglio from comment #42) > (In reply to fujiwara from comment #39) > > (In reply to fujiwara from comment #38) > > > Created attachment 1137645 [details] > > > xev log when press Zenkaku_Hankaku key > > > > > > (In reply to Frediano Ziglio from comment #37) > > > > If desktop freeze looks like a desktop problem. I tested and looks like if > > > > you just press that key and hold Gnome desktop freeze for a while. > > > > You can reproduce even on a bare metal machine. Set keyboard to Japanese, > > > > open htop, press the key and htop will freeze till you release the key! > > > > > > I don't think Zenkaku_Hankaku key itself does not freeze but that unlimited > > > key events cause the desktop freeze so it's a virt-viewer bug. > > > > Sorry typo. > > I don't think Zenkaku_Hankaku key itself freeze but that unlimited key > > events cause the desktop freeze so it's a virt-viewer bug. > > It happens on bare metal too and here there is no virt-viewer. I don't see the unlimited Zenkaku_Hankaku events with a single RHEL7. I can reproduce the issue is reproduced with rhevm & virt-viewer only.
I think the attached two patches to fix the three bugs; bug 1311820, bug 1311858 and bug 1311804.
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