Recovering From Lib Closure

[chris_c]

I've noticed a nasty bug with my PandoraNetPuzzle

Basically when opening the lid after its been closed with the app running the image on the screen is static, it however
hasn't totally hung the machine.

I can ssh into the Pandora (the app is using around 10% cpu time) however if I kill the app or shutdown (with the power
switch held for 10 seconds) then the Pandora does lock up (after starting to shutdown) - with only power-pandora having
any response.

I have tried eglGetCurrentSurface and Context and displaying a message and quitting if I get EGL_NO_SURFACE / CONTEXT
just before eglSwapBuffers, but neither of these tests are triggered.

I'm a bit stumped has anyone got any suggestions?

I'm using SDL_PollEvents is there anything I should be handling there?

 

[skeezix]

No idea offhand whats going on with the GLES stuff during the lid, but a workaround could be ..

Watch for a lid-close event, and then shutdown the GL stuff, and when the lid-opens, bring it back up? (or as a worst case, exit the app when the lid closes, to avoid the problem until it gets sorted out?)

Watching for a lid-open/close is not too difficult; see pndevmapperd code in libpnd, though thats a generic overcomplex approach:
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=blob;f=apps/pndevmapperd.c;h=2214aae86606653d7f332a90b1fe5e5c56d67d93;hb=3059196d8e4dc600832bacd8d8dcbdbb512e9b49

Just want the /dev/eventX type devices for the EV_SW (if memory serves) for the lid.

jeff

 

[chris_c]

No idea offhand whats going on with the GLES stuff during the lid, but a workaround could be ..

Watch for a lid-close event, and then shutdown the GL stuff, and when the lid-opens, bring it back up? (or as a worst case, exit the app when the lid closes, to avoid the problem until it gets sorted out?)

Watching for a lid-open/close is not too difficult; see pndevmapperd code in libpnd, though thats a generic overcomplex approach:
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=blob;f=apps/pndevmapperd.c;h=2214aae86606653d7f332a90b1fe5e5c56d67d93;hb=3059196d8e4dc600832bacd8d8dcbdbb512e9b49

Just want the /dev/eventX type devices for the EV_SW (if memory serves) for the lid.

jeff

Thanks for that - theres some facility to watch for none SDL WM events in SDL - so I'll look at that seeing as I have an SDL event loop already in place...

 

[chris_c]

thx jeff in the end SDL couldnt tell me about the lid so I had to do it the low level way...

closing down GLES and re-initialising it and reloading the textures when the lid is opened works, and I also sit in a loop that sleeps for a second between each check of the lid event so it should be power efficient too!

 

[skeezix]

thx jeff in the end SDL couldnt tell me about the lid so I had to do it the low level way...

closing down GLES and re-initialising it and reloading the textures when the lid is opened works, and I also sit in a loop that sleeps for a second between each check of the lid event so it should be power efficient too!

Awesome, glad it works

So .. if you spin with (say) 30s polls, and the lid closes, and 15s later you detect the event and shut down GL, and then open it up again later .. everything is ok? (ie: you have some time afte lid closes to shut down, or does the shut down have to occur ASAP after closure?)

jeff

 

[WizardStan]

I'm curious what the root cause is. I mean, detecting lid closure and going into an efficient idle loop is a great thing and should be propagated to other things, but to the best of my knowledge it shouldn't be doing anything that actually breaks stuff. It sounds very puzzling to me, and I like a good puzzle.

 

[skeezix]

I'm relatively new to GL/GLES so I've not looked into it .. but suffice to say, most of the code in the drivers is not visible to us is it? (ie: we don't have the code for libGLE etc right?) .. or if SDL was used, maybe its an SDL setup problem.

jeff

 

[WizardStan]

Aye, but all the lid closing does is turn off the backlight and blank the framebuffer, neither act in itself should cause a crash.
I can guess that maybe they gles driver doesn't handle being told it can't draw to the framebuffer very well, but that would seem kind of suspicious.
Actually, thinking on it now, closing the lid causes SNES emulation to start stuttering as well, so maybe there is something to it, even in SDL. I'll have a think, maybe do some hacking this weekend.

 

[chris_c]

Its defiantly a GLES problem SDL apps don't need this handling, as far as I can tell there is no problem with the lid closing it seems to be with lid opening but I could be wrong it has been rather difficult to trace the exact cause as even gdb is no use, while the mouse cursor is functional and you can ssh in after the freeze the instant you try to kill the app or it gets killed as part of a shutdown then the hardware completely locks up.

I can put a test case together next week some time, if people are really want to look further, but as people have already noted without the source to libGLES_CM.so we're out of luck...