Bug 1311820 - Alt-half/full key combination does not work properly in spice console
Alt-half/full key combination does not work properly in spice console
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: mingw-virt-viewer (Show other bugs)
3.5.6
Unspecified Unspecified
high Severity high
: ovirt-4.0.0-rc
: ---
Assigned To: Fabiano Fidêncio
SPICE QE bug list
: OtherQA, ZStream
Depends On: spice_japanese_keyboard 1329600
Blocks: 1332680 1332681
  Show dependency treegraph
 
Reported: 2016-02-25 00:13 EST by Yoshinori Takahashi
Modified: 2016-08-23 16:48 EDT (History)
23 users (show)

See Also:
Fixed In Version: mingw-spice-gtk-0.31-2.el7ev mingw-virt-viewer-2.0-10.el7ev rhevm-spice-client-4.0-2
Doc Type: Bug Fix
Doc Text:
Previously, Zenkaku_Hankaku key combinations on Japanese keyboards were not working properly when using spice-gtk. Now, support for the Zenkaku_Hankaku key has been added to spice-gtk.
Story Points: ---
Clone Of:
: 1332680 1332681 (view as bug list)
Environment:
Last Closed: 2016-08-23 16:48:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Spice
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xev log when press Zenkaku_Hankaku key (85.40 KB, text/plain)
2016-03-17 22:09 EDT, fujiwara
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:1681 normal SHIPPED_LIVE rhevm-spice-client bug fix and enhancement update for RHV 4.0 2016-09-02 17:09:20 EDT

  None (edit)
Comment 2 Frank DeLorey 2016-02-25 09:27:32 EST
So both the client and the guest are running Windows 7?
Comment 3 Fabiano Fidêncio 2016-02-25 15:40:20 EST
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.
Comment 33 Frediano Ziglio 2016-03-11 05:06:51 EST
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).
Comment 37 Frediano Ziglio 2016-03-17 06:43:58 EDT
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!
Comment 38 fujiwara 2016-03-17 22:09 EDT
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?
Comment 39 fujiwara 2016-03-17 22:11:48 EDT
(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.
Comment 42 Frediano Ziglio 2016-03-19 13:07:05 EDT
(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.
Comment 43 fujiwara 2016-03-22 02:40:40 EDT
(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.
Comment 55 fujiwara 2016-03-25 19:26:02 EDT
I think the attached two patches to fix the three bugs; bug 1311820, bug 1311858 and bug 1311804.
Comment 68 Yaniv Lavi 2016-05-09 07:01:15 EDT
oVirt 4.0 Alpha has been released, moving to oVirt 4.0 Beta target.
Comment 75 errata-xmlrpc 2016-08-23 16:48:58 EDT
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

Note You need to log in before you can comment on or make changes to this bug.