Open quinkennedy opened 11 years ago
Hey @quinkennedy thanks for the report. Does this happen consistently with the latest develop-raspberrypi branch or is it happening sporadically? Has it happened with any of the other examples for you?
So just a little background info -- when the ofAppEGLWindow
starts up on the RPI, it caches the current terminal settings and then disables normal terminal input (i.e. echoing etc) so that the app gets the keystrokes and the terminal doesn't.
Normally, during shutdown, those cached terminal settings are restored, allowing you to see your terminal input, etc.
If for some reason the app didn't shut down completely, it is possible that those terminal settings didn't get applied, resulting in an invisible cursor and residual app on screen.
So, next step is to figure out how to reproduce the bug -- any other info you can provide is helpful!
I am using a dvorak keyboard, and noticed that hitting the key that maps to 'f' in dvorak didn't fullscreen the app, but hitting the key that corresponds to 'f' on the querty keyboard did toggle fullscreen. Could it be that when I hit Ctl+c in dvorak, the system killed the app, but the app itself interpreted the key combination as Ctl+i?
Yeah, it certainly could interpret it incorrectly as the window currently is not aware of any special keyboard mappings (although it seems like it should be picking up the same keyboard config as you set up in linux ... not sure about that). If you quit with the "real" Ctrl+c, does it quit correctly?
Just to clarify, the app won't directly interpret the Ctrl+i per se -- it will respond to the kill and other signals via sighandlers (i.e. signal(SIGINT, xxx)
which I believe I added to ofAppRunner
(I can't recall and can't look deeper right now). So, it may be possible that the signal handlers I installed are missing a signal and preventing the normal app shutdown sequence ...
Can you tell if the exit
function in ofAppEGLWindow
is being called?
sorry for pulling the trigger so soon, I can't reproduce.
though I can reproduce its not interpreting the 'f' key in dvorak.
If you are still having the issue, I'd like to get a little more clarification on the situation. Can you confirm that this is related to the keyboard hardware / linux interaction? Or do you think it is in the code? Basically, if there is a code bug, I want to figure out how to fix it. If it is just a RPi + unusual hardware config (i.e. w/ the dvorak keyboard), then I want to add a note to the FAQ / documentation in case people don't search the issues, etc.
If you think it is just a matter of the dvorak keys being interpreted incorrectly, I'd also like to add a note on that to the documentation.
Thanks for your help on this!
well I tried running the application about ten more times, and did not encounter the freeze again. But the key mapping thing (used just for simple keyboard interaction, in this case, pressing 'f' to toggle fullscreen) is a consistent issue. I have encountered it in the past on various games and such in windows and osx, I don't remember testing the issue with Open Frameworks in specific before on other platforms.
I ran the windowExample under OSX 10.7.5 and it handled the dvorak mapping correctly.
Hey there, I'm still suspicious about the original hang, but perhaps at least we can figure out the dvorak issue.
Have you seen this post:
any updates? @quinkennedy @bakercp
no updates.
I was running the windowExample in examples/utils and when I wanted to quit I hit Ctl+c
This caused the application to pause, but it is still displaying on screen and will not return me to the command prompt. If I hit enter, the text in the background moves up, but typing keys does nothing.
I ran the example straight from the CLI, I never started up xwindows.
rPI w/ 512 MB memory & 32 Gig SD card. USB mouse and keyboard.