Bug 1286808

Summary: Keys are stuck and not released in virt-viewer under excellent network conditions
Product: Red Hat Enterprise Linux 7 Reporter: Mike <mike.benoit>
Component: spice-gtkAssignee: Default Assignee for SPICE Bugs <rh-spice-bugs>
Status: CLOSED INSUFFICIENT_DATA QA Contact: SPICE QE bug list <spice-qe-bugs>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.3CC: dblechte, fziglio, mkalinin, pvilayat, victortoso
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-03-22 20:40:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mike 2015-11-30 19:01:41 UTC 
Description of problem:

Intermittently keys are getting "stuck", using remote-viewer v2.00 and spice-gtk 0.30. I think the issue is similar to the following bug reports:

https://bugzilla.redhat.com/show_bug.cgi?id=1086650
https://bugzilla.redhat.com/show_bug.cgi?id=812347

The main difference being that it happens on a low latency/low jitter network, and the keys getting stuck are primarily modifier keys (CTRL the most, sometimes ALT & SHIFT). The most common case is using CTRL+C/CTRL+V to copy/paste, and the CTRL gets stuck or the "C" gets stuck.

Latency/Jitter example (local gigabit network):
PING 10.7.5.11 (10.7.5.11) 56(84) bytes of data.
64 bytes from 10.7.5.11: icmp_seq=1 ttl=64 time=0.222 ms
64 bytes from 10.7.5.11: icmp_seq=2 ttl=64 time=0.191 ms
64 bytes from 10.7.5.11: icmp_seq=3 ttl=64 time=0.205 ms
64 bytes from 10.7.5.11: icmp_seq=4 ttl=64 time=0.198 ms
64 bytes from 10.7.5.11: icmp_seq=5 ttl=64 time=0.200 ms
64 bytes from 10.7.5.11: icmp_seq=6 ttl=64 time=0.161 ms
64 bytes from 10.7.5.11: icmp_seq=7 ttl=64 time=0.121 ms
64 bytes from 10.7.5.11: icmp_seq=8 ttl=64 time=0.183 ms
64 bytes from 10.7.5.11: icmp_seq=9 ttl=64 time=0.130 ms
64 bytes from 10.7.5.11: icmp_seq=10 ttl=64 time=0.192 ms

--- 10.7.5.11 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8997ms
rtt min/avg/max/mdev = 0.121/0.180/0.222/0.032 ms


Version-Release number of selected component (if applicable):

remote-viewer v2.00 
spice-gtk 0.30

How reproducible:

Unfortunately we can't reproduce it at will, but it seems to happen about 1-3x per day, even with "xset r off" on the client.

Previously when using spicec or remote-viewer v1.00 and spice-gtk 0.28 it seemed to happen around 4-6x per day and with more than just the modifier keys. However since upgrading to remote-viewer v2.00 and spice-gtk 0.30 it has reduced the occurrences significantly. Usually tapping the key that got stuck a few more times seems to "unstick" it.
Comment 1 Victor Toso 2016-02-18 11:50:32 UTC 
Hi, thanks for taking time to report this bug.

(In reply to Mike from comment #0)
> Version-Release number of selected component (if applicable):
> 
> remote-viewer v2.00 
> spice-gtk 0.30

I've cloned this bug upstream at:
https://bugs.freedesktop.org/show_bug.cgi?id=94205
Comment 2 Pawan kumar Vilayatkar 2017-09-05 09:40:42 UTC 
Hello ,

The upstream bugzilla :

>> https://bugs.freedesktop.org/show_bug.cgi?id=94205

which talks about setting SPICE_KEYPRESS_DELAY to 0 and more investigation shows an other setting named SPICE_INPUTS_CAP_SCANCODE which i can't find any documentation for.
is this something to test? and do have info about SPICE_INPUTS_CAP_SCANCODE?
Comment 5 Mike 2018-06-05 16:23:44 UTC 
The frequency of occurrence has greatly diminished to the point where the complaints seem to have mostly stopped. We have upgraded to remote-viewer v2.00 and recently v6.00 and we do set SPICE_KEYPRESS_DELAY=0.