Hide Forgot
Description of problem: This bug was reported within F-13 and F-14 (Bug# 607866) and the bug exists in RHEL 6.1 as well. Selectively characters will start repeating (and they are not, usually, the last character typed at that). Fingers do not need to be on the keyboard at the time the characters start to repeat, but a keystroke is needed to stop the repeat. Version-Release number of selected component (if applicable): tigervnc-1.0.90-0.15.20110314svn4359.el6_1.1.x86_64 How reproducible: Not reproducible, but happens with regularity. In most cases it seems that a VNC session needs to be kept 'active' for a couple of days before the problem starts to manifest itself. A termination of the VNC session and a creation of a new server session clears the condition (but then eventually starts the character repeating problem again). This problem is particularly troublesome when the characters start to repeat within a text editor. Bug# 607866 suggests a fix has been applied for the tigervnc version in F-13/F-14 -- can a similar fix be applied for next release in RHEL 6.x too?
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
This bug also exists in RHEL 6.2. It is not reproducible, but happens with a fair bit of frequency. It seems to occur most often after a VNC session has been active for several weeks. The only workaround is to terminate the VNC server and create a new session and the problem will not re-occur for a period of time later (days/weeks, usually not hours). There seems to be ample documentation on the Web of others experiencing this same problem with code patches identified that would (hopefully) fix this bug once and for all, it just needs to be applied to tigervnc-server-1.0.90-0.17.20110314svn4359.el6.x86_64 and made available for all future RHEL 6.x releases.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate, in the next release of Red Hat Enterprise Linux.
It would be useful to capture the TCP traffic at the point the problem is present. To do that: 1. On either the client machine or the server machine, run this command as root: tcpdump -ni eth0 -s 0 -U -w rfb.pcap port 5901 This will start capturing TCP data on network interface eth0 (you may need to adjust this) to/from TCP port 5901 (this is 5900 + VNC display number -- you may need to adjust this). It is best to do this outside of the VNC session (e.g. an ssh login) to avoid problems with typing the command in. Leave this command running while you carry out the next step: 2. In the VNC session, demonstrate the problem. When you see that a key is being repeated, please wiggle the mouse. This sounds silly but the "move mouse pointer" commands will help me to see at which point the problem was occurring. Please demonstrate the problem a few times. 3. Now return to the tcpdump command. Press Ctrl+C to stop it. Run "du -h rfb.pcap" to check that it has recorded data: it should be fairly large. If it is only a few kilobytes then it has not worked (check the RFB port number and network interface name). 4. Finally, compress that file: "xz rfb.pcap". Please attach rfb.pcap.xz. I will analyse it to find out the nature of the problem.
Please close this bug. WE are now at RELH 6.5 and the bug did not show up any longer. Thanks, Stefano Ionescu-Niscov
Thanks. I think the fix for bug #1054118 might have also fixed this then.