On Saturday 02 June 2007 06:59, Joseph Loo wrote:
I get a multiplication when doing it. I do not think it is tightvnc that is doing it because, if you open a standard xterm, it comes out as 8. Yes, that is my result also... that is why I used xev... because it will tell me exactly which keysyms are being sent to KDE and being interpretted by KCalc... this is the update I sent to the tightvnc people:
</begin> I am using tightvnc 1.2.9 which shipped with openSUSE 10.0. I have several headless application servers serving shared kde desktops across ssh tunnels with the vncviewer also running as the client on openSUSE 10.0. This setup is working great, and I want to thank the team who is making GPL tightvnc possible. 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! I'll keep you posted. :-| -- Kind regards, M Harris <>< -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org