Bug Tracker item #3000363, was opened at 2010-05-12 12:16 Message generated for change (Comment added) made by atkac You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3000363&group_id=254363
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: UN*X version Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Siberiss (siberiss) Assigned to: Adam Tkac (atkac) Summary: numpad keyboard problems Initial Comment: On Fedora 12 and Fedora 11 x86_64 installations, the numpad KeySyms XK_KP_0 -> XK_KP_9 and XK_KP_Decimal are not handled correctly (at least for our standard Dell US usb keyboards). The behaviour as observed with xev is that numpad keystrokes with Num_Lock on are always pre-shifted with Shift_L. This way, pressing XK_KP_1 has the same result as pressing XK_KP_End, since with Num_Lock off everything works as expected. A quick look in the tigervnc sources reveals the problem: in the xorg x11 source file 'usb-keyboard.c', the KeysSyms XK_KP_0 -> XK_KP_9 and XK_KP_Decimal are in the first column, This way, the InputDevice::keyEvent(...) function in tigervnc's 'Input.cc' generates an unwanted fake shift press, as explained in the comments above the function: "...column 1 means shift must be pressed and mode_switch released, " The patch attached fixes the issue for our system configuration, but there's no guarantee it doesn't mess up existing working systems. The patch has been done against the source from 'tigervnc-1.0.1-1.fc12.src.rpm' (latest patch was tigervnc11-r4025.patch). It's just a quick hack and i assume there are other and better solutions, but it correctly resolves our issue and the numpad is now finally usable in vnc sessions. ---------------------------------------------------------------------- >Comment By: Adam Tkac (atkac) Date: 2010-06-14 17:18 Message: After more detailed inspection this was really bug in the Xvnc, it should be fixed in trunk (revision 4057). Just for information, although the attached patch might solve this issue, it only hides the real problem. ---------------------------------------------------------------------- Comment By: Henry Wong (henry128) Date: 2010-05-14 04:56 Message: I've seen a similar workaround posted here: http://forums.gentoo.org/viewtopic.php?t=47846 I use a script in /etc/X11/xinit.d/ that checks if the current session is a VNC session, then uses xmodmap to tinker with entries dealing with the numpad. I think it's quite similar to your workaround, as it also needs XKB. Keyboard handling code is messy... ---------------------------------------------------------------------- Comment By: Siberiss (siberiss) Date: 2010-05-12 17:25 Message: I think you are right about the special meaning of Shift-Left and Shift-Right in Konsole and others. After trying a lot of things, I found the following workaround: 1: make sure 'xorg-x11-xkb-utils' and 'xkeyboard-config' are installed (Fedora packages). 2: get the source rpm of tigervnc where Xvnc supports the XKB extension (tigervnc-1.0.1-1.fc12.src.rpm seems to be fine) 3: comment out the code in Input.cc, function InputDevice::keyEvent(...) responsible for the fake keypresses with the ModifierState class: /* commented out, not needed if the correct XKB keymap is loaded ModifierState shift(keyboardDev, ShiftMapIndex); ModifierState modeSwitch(keyboardDev, modeSwitchMapIndex); if (down) { if (col & 1) shift.press(); else shift.release(); if (modeSwitchMapIndex) { if (col & 2) modeSwitch.press(); else modeSwitch.release(); } } */ This seems to be ok since the numpad keys were the only keys in column 1 of usb-keyboard.c that are pressed without shift already pressed. The others in column 1 (like XK_percent and XK_greater) are always pressed after the user has pressed the shift key first, so the ModifierState is not necessary if the correct XKB keymap is loaded. The reason why the fake shift modifier is not necessary with this XKB keymap, I don't know... 4: repackage and compile/install 5: edit the ~/.vnc/xstartup script so that the correct XKB keymap is loaded. I added the following line before the xinitrc part: setxkbmap us -print -display $DISPLAY | xkbcomp - $DISPLAY 6: numpad works as expected in KDE, both with num lock on and with num lock off. ---------------------------------------------------------------------- Comment By: Pierre Ossman (ossman_) Date: 2010-05-12 16:43 Message: I've tested this now, and Qt/KDE/Konsole is indeed doing something funky here. They probably want the key combination Shift-Left to be special and they're trying to do this even when Shift changes the symbol the key generates. Not much we can do about this unfortunately as we need to fake the Shift in order to generate the correct symbol. ---------------------------------------------------------------------- Comment By: Siberiss (siberiss) Date: 2010-05-12 13:53 Message: The problem appears globally in all KDE sessions over VNC. An example is that when a second konsole tab is opened, pressing XK_KP_4 does not result in the character '4' being printed on the screen, but instead konsole switches to the other tabbed window as it would do when pressing XK_KP_Left. With xev, i get the following after pressing XK_KP_4 (Numlock on): KeyPress event, serial 29, synthetic NO, window 0x2600001, root 0xf6, subw 0x0, time 2840318958, (210,732), root:(214,755), state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 29, synthetic NO, window 0x2600001, root 0xf6, subw 0x0, time 2840318958, (210,732), root:(214,755), state 0x1, keycode 83 (keysym 0xffb4, KP_4), same_screen YES, XLookupString gives 1 bytes: (34) "4" XmbLookupString gives 1 bytes: (34) "4" XFilterEvent returns: False KeyRelease event, serial 29, synthetic NO, window 0x2600001, root 0xf6, subw 0x0, time 2840318958, (210,732), root:(214,755), state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 29, synthetic NO, window 0x2600001, root 0xf6, subw 0x0, time 2840319162, (210,732), root:(214,755), state 0x0, keycode 83 (keysym 0xff96, KP_Left), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False I think I understand that the fake shift press is necessary since Xvnc always assumes the numlock key to be off (I can be wrong), but I still think the problem has something to do with the fake press being released before the actual release (as you can see in the xev output above)... ---------------------------------------------------------------------- Comment By: Pierre Ossman (ossman_) Date: 2010-05-12 13:35 Message: This is perfectly acceptable X11 behaviour. The same thing will happen if you do the same sequence manually against a local X server. IOW, if this sequence is causing problems for your application then that application needs to be fixed, not VNC. Could you elaborate on which application you are using and what the symptoms of your problem is? ---------------------------------------------------------------------- Comment By: Siberiss (siberiss) Date: 2010-05-12 13:18 Message: Apperently the issue is bigger and i was a little too lazy in my testing. For local vnc sessions, the issue is resolved, remote sessions still lack numpad support. I guess the other and correct solution is to make sure that the ModifierState class triggers the fake Shift_L release event after the numpad key was released, instead of before as it does now. Before the (incomplete) patch, the order of the events when pressing XK_KP_1 was: (fake) press Shift_L -> press XK_KP_1 -> (fake) release Shift_L -> release XK_KP_End. Notice that the pressed key is different from the relased key, due the fact that the fake release comes before the actual release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3000363&group_id=254363 ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
