keysdown, repeat keys, multi-platform

jwkuehne · Post by **jwkuehne** » Sun Dec 21, 2008 1:02 am

In Windows and Linux with repeat keys on, one gets a stream of rawkeydown and rawkeyup messages, while in OS X this is not the case. Does the keysdown function reflect this toggling in Linux and Windows, or does it show the physical state of the key held down, even when a key repeat sends rawkeyup? I haven't tried a test stack to see if keysdown correctly shows the physical state of the key, but even if it seems to work, I'm leery in my application of the possibility of rare race conditions, as I'm moving about 65 tons of machinery. Sure would be nice to have the definitive answer based on the source code to RR.

Of course I could just turn off repeat keys in Linux/Windows, but I can't trust my users to do the same.

-John

PS has anybody else found that turning off repeat keys in Vista is incredibly difficult bordering on silly? Of course Vista is dead, but the next monster from Micr*soft may be worse.

Mark · Post by **Mark** » Sun Dec 21, 2008 7:24 pm

Hi John,

On my Mac, running Leopard, the rawKeyDown message is sent as long as the key is down.

Best,

Mark

jwkuehne · Post by **jwkuehne** » Mon Dec 22, 2008 6:29 pm

It's easy to latch the stuff in rawkeydown so it doesn't get executed repeatedly from a stream of rawkeydown. The issue is the stream of rawkeyup.

Here's my attempt to turn off both unwanted effects - i.e. up/down messages - of repeat keys, by latching and unlatching. This seems to work, but it depends on the eternal truth of "the keysdown". One might guess that on rawkeyup the key should be reported as "up", but it seems, hopefully, that RR is instead checking the actual physical state of the key: it's down.

Again, can anyone in RR confirm this behavior of "the keysdown", or is the fact that keysdown seems to work here is just a happy coincidence waiting to be broken by future versions or race conditions?

If a keyboard buffer overflow, or some other effect, causes the rawkeyup to go unsent, then this code sticks, and a watchdog using idle might be required. Also, this code does more than prevent repeat keys: you don't get the next keystroke unless you've lifted your finger off the previous key.

on rawkeydown x
global kd
if kd is empty then
put x into kd
pass rawkeydown
end if
end rawkeydown

on rawkeyup x
global kd
if x is not among the items of the keysdown then
put empty into kd
pass rawkeyup
end if
end rawkeyup

Mark · Post by **Mark** » Mon Dec 22, 2008 7:02 pm

Hi Jon,

I don't know why you want this, but it should be unnecesary. If the repetition speed is too fast for people, they can change it in the system settings. Why bother?

Best,

Mark

jwkuehne · Post by **jwkuehne** » Mon Dec 22, 2008 9:12 pm

Answer: My application controls 65 tons of telescope - through a keyboard. One of the functions is to slew the telescope in HA and DEC while holding down on two keys. Keyboard response time has to better than 100 milliseconds, i.e. instant off when commanded.

Already you might see why I don't want *any* repetition speed: I can't allow the motors to flutter on and off because of repeat keys, yet the keys need to be exquisitely responsive to release. You can't trust users to turn off keyboard repeats, nor should they have to. I can, in Linux, force the job by doing "xset r off", but that turns off repeats for everything, and that's not an ideal solution - if only because users can turn repeats back on without understanding the issue - but it's what I'm doing now.

Keyboard repeats are totally bozo busted in Windows and Linux, and they will always stay broken for historical reasons related to teletypes. It would be like a mouse sending only repeated mouseDown/mouseUp messages. The only sane thing for a mouse is to send mouseDown, mouseStillDown, and mouseUp messages, which is what a mouse does. Keyboards shouldn't repeat: it should be up to the application to decide how to handle a held-down key, not some system-wide property that applies to all apps whether they want it or not.

At one time I used wait handlers like

Code: Select all

wait until the south_key is not among the keysdown with messages

but wait handlers are not asynchronous: they are stacked. Often the scope is moved in two axes simultaneously, and the stacked behavior of wait commands causes obvious problems here, since you may want to stop the first commanded motion while leaving the second going, i.e. you have reached your target in RA but not DEC.

I still use the wait command for the mouse N-S-E-W buttons, because you can only press one button at a time with the mouse. For example

Code: Select all

on mouseDown
 startMotion
 
 wait until (the mouse is up) or (the mouseloc is not within the rect of me) with messages

 endMotion
end mouseDown

You could also use a mouseUp handler here, but why bother? (originally I avoided the mouseUp handler because I was doing blocking socket IO twice a second, and sometimes the mouseUp wouldn't be sent if the mouse was released while reading the socket. Crashing a 2.1m telescope because a mouseUp didn't get sent is a disaster. I now do asynchronous (non-blocking) socket transactions, which have their own set of bugs in RR.)

You can find out more here:

http://snoopy.as.utexas.edu:8080/OS/man ... ng-track82

and a photo

http://snoopy.as.utexas.edu:8080/OS/new ... -installed

gyroscope · Post by **gyroscope** » Mon Dec 22, 2008 9:37 pm

and a photo

http://snoopy.as.utexas.edu:8080/OS/new ... -installed

Wow, now that I call impressive!

jwkuehne · Post by **jwkuehne** » Mon Dec 22, 2008 9:47 pm

Take a look at the QuickTime animation link at the bottom of

http://snoopy.as.utexas.edu:8080/OS/tec ... -mechanism

I did this app in Revolution, and saved separate frames for the QT movie.

But the app itself is "real time": it has a slider for speed, and a three-pole switch for clockwise/off/counterclockwise. RR programmers will recognize the use of transparency and blending that allows you see the gears through the planet carriers. Also, the color-coded text annotation of the blueprint was done in RR.