Bug Tracker item #3000363, was opened at 2010-05-12 12:16 Message generated for change (Comment added) made by ossman_ 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: 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 ------------------------------------------------------------------------------ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
