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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
