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 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
------------------------------------------------------------------------------
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
