Description of problem: Update tigervnc-1.0.90-0.13.20100420svn4030.fc13 (Bug ID: 611677) fixed the ability to type on the keyboard with a VMWare Workstation 7.x VM. Now after more discovery, certain keys on the keyboard to not type out correctly. In particular the less-than key (<) always types out as a greater-than key (>). Version-Release number of selected component (if applicable): Fedora 13 How reproducible: Steps to Reproduce: 1. Update tigervnc to version: tigervnc-1.0.90-0.13.20100420svn4030.fc13 1. Start up a VNC session 2. Bring up VMware WorkStation 7.x 3. Bring up a linux VM 4. Type a less-than sign within a gnome-terminal window Actual results: less-than signs type out as greater-than signs Expected results: less-than signs should type out as less-than-signs Additional info: Will be glad to test out possible fixes...
Can you please check if tigervnc-server-1.0.90-0.15.20100420svn4030.fc13 is fine? (it is currently in updates-testing and will land into stable soon).
Adam: Just tried out the testing RPM: tigervnc-server-1.0.90-0.15.20100420svn4030.fc13. The same issue is occurring. I also updated VMware Workstation to version 7.1.2. I checked out all other possible keys and they seem to be OK. The only one that is an issue is the "less-than" sign. Of course this prohibits me from using I/O redirection (input) on the command line.
Adam: Have you had a chance to figure this one out? rwhalb
I'm working on this issue, please be patient.
Can you please check if rpms on http://atkac.fedorapeople.org/tigervnc are fine? (tigervnc-server-1.0.90-0.15.20100420svn4030.fc13.1). Thank you in advance.
Adam: Just updated to: tigervnc-server-1.0.90-0.15.20100420svn4030.fc13.1.x86_64 The results are no good. Now significantly more keys are not working: The '<' (less than) key still comes out as the '>' (greater than) key Now these keys do not come out at all: > ? ! @ # $ % ^ & * ( ) _ all the shift symbol keys... In the past you had me give you log output. Would that be helpful? rwhalb
Adam: Just updated to: tigervnc-server-1.0.90-0.15.20100420svn4030.fc13.1.x86_64 The results are no good. Now significantly more keys are not working: The '<' (less than) key still comes out as the '>' (greater than) key Now these keys do not come out at all: > ? ! @ # $ % ^ & * ( ) _ all the shift symbol keys... In the past you had me send you log output. Would that be helpful? rwhalb
(In reply to comment #8) > Adam: > > Just updated to: tigervnc-server-1.0.90-0.15.20100420svn4030.fc13.1.x86_64 > > The results are no good. > > Now significantly more keys are not working: > > The '<' (less than) key still comes out as the '>' (greater than) key > > Now these keys do not come out at all: > > > ? ! @ # $ % ^ & * ( ) _ all the shift symbol keys... > > In the past you had me send you log output. Would that be helpful? I don't need the log right now. I've read VMWare documentation (particularly http://www.vmware.com/support/ws55/doc/ws_devices_keymap_linux.html) and I've probably found the root cause of this issue. Can you please try to put following line into your ~/.vmware/config (or /etc/vmware/config for system-wide effects) on the machine where you have VMWare Worstation installed?: xkeymap.nokeycodeMap = true This setup assumes you use standard US keyboard. Please use tigervnc-server from link written in comment #5.
Adam: OK, added: xkeymap.nokeycodeMap = true in either file ~/.vmware/config or /etc/vmware/config and did not fix the problem. I tried with both RPM versions: tigervnc-server-1.0.90-0.15.20100420svn4030.fc13.1.x86_64 - same issues existed as reported in Comment: 8 and the current stable: tigervnc-server-1.0.90-0.15.20100420svn4030.fc13.x86_64 - sames issues existed as reported in Comment: 1 ---rwhalb
I've finally managed to get VMware Workstation working on my machine. After inspection this is WMware workstation issue, please report it to VMware. You can write something like this to the report: Note that I assume "xkeymap.nokeycodeMap = true" option is set so VMware should interpret keysyms, not keycodes. When VMware Workstation grabs mouse & keyboard input, it removes all modifiers from X server's modifier map. Previously, Xvnc wasn't able to handle this situation well - it was bug #611677. However now Xvnc (with small patch, I will release an update) behaves correctly, let me explain background of the "<" issues. When you type the "<" character on the vncviewer side then vncviewer sends "Shift" and "less" X11 keysyms to the server. Server correctly decides you would like to press "<" and starts to generate key press event, based on it's keyboard map. This is common US map: $ xmodmap -pke |grep less KEYCODE = COL1 COL2 COL3 COL4 keycode 59 = comma less comma less keycode 94 = less greater less greater bar brokenbar The first column is used when no modifier is active, the second column is used when "Shift" modifier is active. As I wrote above VMware workstation clears modifier map so "Shift" has no effect and the first column is always used. So Xvnc emits this keypress: "Shift" and "keycode 94". /usr/bin/xev utility correctly translates this sequence to the "less" keysym. However VMware workstation outputs this as "greater" keysym, which is a bug. Feel free to redirect questions of VMware developers to me, I will answer them if they need more information.
Adam: I also have a Fedora 12 server running with the tigervnc-server-1.0.0-1.fc12.x86_64 build. I have no issue with the "<" key on this system. It is running the latest VMWare Work Station: 7.1.2 build-301548 I am confused on how this would be a VMware workstation issue? I just want to make sure with you that you had this information. Please advise... ---rwhalb
Adam: I started up a Vino (VNC-Server for GNOME) session on the same system that is using running VMWare Work Station: 7.1.3 build-324285. I used a tiger VNC client (vncviewer) on a Mac OS X system and have no problems with the "<" key. Is there something you can look at in the Gnome Vino VNC server code to help resolve this issue? Thanks... ---rwhalb
Adam: Happy new year. Have you had a chance to revisit this particular isssue. I will be glad to work with you to resolve. Thanks for you support... ---rwgalb
Adam: Just applied the update RPM: tigervnc-server-1.0.90-0.16.20100420svn4030.fc13.x86_64 package. The problem still exists with the "<" key under VMWare Work Station: 7.1.3 build-324285. Do you think you will be able to resolve this issue? ---rwhalb
I added another hack into Xvnc which should fix this issue. Can you please check tigervnc-server (1.0.90-0.16.20100420svn4030.fc13.1) from http://atkac.fedorapeople.org/tigervnc? Thank you in advance.
Adam: OK now updated to 1.0.90-0.16.20100420svn4030.fc13.1 No joy... Now the Shift key is not honored for most keys. Therefore no capital letter or special chars: !@#$%^&*() However, the only shift key that now works is the "<" key (The key that was previous not working). So your logic for the fix is close. Let me know when you can get back to this. I will revert back to the previous tigervnc-server RPM - since I can not log in now without the shift key working... ---RWH
(In reply to comment #18) > > Let me know when you can get back to this. I will revert back to the previous > tigervnc-server RPM - since I can not log in now without the shift key > working... I will give you another test rpm tomorrow.
I did more investigation and it seems the issue is in the X.Org server (Xvnc is based on it). I reported bug to upstream (https://bugs.freedesktop.org/show_bug.cgi?id=34435), will create another test rpm when Xorg team fixes the issue.
Adam: I see that X.Org still has not responded to you as of yet. Any more status on this. Still eagerly waiting for a fix... ---RWH
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Adam: I just updated this for Fedora 15. The problem still persists. Currently have: [root@probe-eth0 ~]# uname -a Linux probe-eth0 2.6.38.8-32.fc15.x86_64 #1 SMP Mon Jun 13 19:49:05 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux [root@probe-eth0 ~]# rpm -q tigervnc-server tigervnc-server-1.0.90-4.fc15.x86_64 VMware Workstation 7.1.4 build-385536 "<" left shift key still shows up as ">" the right shift key. I appreciate if this can be finally addressed. I will be glad to assist with debugging... Thanks you... ---RWH
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping