On Sunday 03 June 2007 01:27, M Harris wrote:
I have a minor concern with the way the numeric keypad is handled, and I am wondering whether this has already been addressed, or if I need to open a bug report. I did some searching but did not find what I was looking for.
In version 1.2.9 the numeric keypad is not being handled properly when the numlock is on. From my vncviewer client I am accessing my remote kde desktop and running (from within a konsole) the xev tool. This displays the x events (keypresses and keyreleases) plus the associated keysyms. With the numlock off the keypad works as I would expect it to. The 7 key is keysym KP_Home, the 8 key is KP_Up, etc. Each key receives ONE keypress event, and ONE keyrelease event. However, when the numlock is on then the behavior is not expected which causes different kinds of problems depending which app is needing the keypad. With numlock on the 7 key recieves [ in this order ] : keypress shift_L keypress KP_7 keyrelease shift_L keyrelease KP_Home [ this is not correct behavior, even though it does work for some things ] The 8 key press with numlock on gives: keypress shift_L keypress KP_8 keyrelease shift_L keyrelease KP_Up [again, not correct and very strange behavior in some apps]
The shift meta keys should not be used at all--- although the technique would work for the most part if the keyreleases were in the correct order. Here is what happens in kcalc --- the 8 key activates the * key [multiplication key] why?-- because the 8 is being interpretted as an "8" with the shift_L key down... "*".
Using the shift_L technique vncviewer should be sending the keyrelease shift_L *last*. However, even so, it will not work in KCalc because the 8 key will still be interpretted as an * .
What should be happening is this: keypress Num_Lock keyrelease Num_lock keypress KP_8 keyrelease KP_8
So, I would like to know is this a bug? If so, has it been fixed in 1.3.x (I have downloaded the tarball but have not installed it as yet)? Is there a work-around in the current version, or is there something I am missing here?
</end>
The tightvnc folks say to install the 1.3.9 version... which I *have* downloaded, but which I have not installed as yet. They tell me that the old version numlock state was the state of the Server PC instead of the Client PC. When the client pushes numlock the numlock comes on at the client but stays off at the server<?>. Yikes. I am playing with that now... but have not confirmed that that is my problem. I still think its a bug in vncviewer. Different apps give different results depending on whether the keyreleases are valid symbols for the app!
Ummmmm,,,,This a way off the wall suggestion. I remember a thread a while ago about the left and right shift keys being mapped differently. Maybe ?? Bob S -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org