Version-Release number of selected component (if applicable): kvm-74-6.fc10.x86_64 virt-manager-0.6.0-3.fc10.x86_64 Steps to Reproduce: (Tested with a Czech locale, the labels may not match exactly) 1. Open System/Settings/Hardware/Keyboard 2. On the layout tab, click on "Restore default" (only one USA layout) 3. "Add" a layout: Czech Republic, Czechia qwerty 4. In "Layout options", set: Ctrl key position - Make CapsLock an additional Ctrl Layout switching - R-Alt switches layout while pressed Use keyboard LED to show alternative layout - CapsLock LED shows ... (perhaps none of these are relevant - but this is the environment I use) 5. Start virt-manager, install a rhel5 guest, start it, switch to console Try typing "rhn_register", verify it works as expected 6. In "Layout options" as above, set: Layout switching - Both Shift keys together change layout 7. Start the rhel5 guest again (or continue using the previous sesssion). Try typing rhn_register. Actual results: Shift key release ignored, so the result is rhn_REGISTER. The following messages appear in the console: atkbd.c: Unknown key released (translated set 2, code 0x0 on isa0060/serio0). atkbd.c: Use 'setkeycodes 00 <keycode>' to make it known. Expected results: Shift key release handled as expected.
This might be caused by keysyms in the keyboard layout: Press left shift: KeyPress event, serial 27, synthetic NO, window 0x4600001, root 0x7f, subw 0x0, time 4530759, (41,81), root:(44,658), state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False Release left shift: KeyRelease event, serial 30, synthetic NO, window 0x4600001, root 0x7f, subw 0x0, time 4530806, (41,81), root:(44,658), state 0x1, keycode 50 (keysym 0xfe0a, ISO_Prev_Group), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False Press right shift: KeyPress event, serial 30, synthetic NO, window 0x4600001, root 0x7f, subw 0x0, time 4533907, (41,81), root:(44,658), state 0x0, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False Release right shift: KeyRelease event, serial 30, synthetic NO, window 0x4600001, root 0x7f, subw 0x0, time 4533986, (41,81), root:(44,658), state 0x1, keycode 62 (keysym 0xfe08, ISO_Next_Group), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False
Can you give these packages a try and say if they make any useful difference http://kojipkgs.fedoraproject.org/packages/gtk-vnc/0.3.8/1.fc11/ Key modifier handling in VNC is a trainwreck, and this new release tries to un-wreck things in a different way to current F10 gtk-vnc. Its 50/50 whether it actually helps you though....
Yes, 0.3.8 that seems to work fine.
Built for both F10 and F9 into gtk-vnc-0.3.8-1.fc10/fc9
gtk-vnc-0.3.8-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/gtk-vnc-0.3.8-1.fc10
gtk-vnc-0.3.8-1.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gtk-vnc'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11128
gtk-vnc-0.3.8-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.