Fix for issue "Suspend causes oxide to crash on RM2 #113"

[Witos]

No description provided.

[Eeems]

Any chance you could work on testing the timings soon?

[SyntaxBlitz]

Tested this build with rm2fb shim with the two attached files (the first is solid grey, the second is noisy), and it works fine for me (compared to the toltec build which does crash).

Worth mentioning that although tarnish doesn't crash anymore, I'm not sure it's totally finishing the render.. sometimes the screen doesn't get completely cleared:

I'm also sometimes having trouble waking from suspend, though honestly it could just be because sometimes I have trouble hitting the power button on this thing.

[Eeems]

Waking could also be #97
What timing are you using where it doesn't have enough time? And is it for both images or just one?

[SyntaxBlitz]

That's with this artifact: https://github.com/Eeems/oxide/pull/114/checks?check_run_id=1623126791 which I think is 0.6s. I only noticed it on the solid grey screen, though it wasn't happening consistently (just got it to render fine) so it could also be an issue on the noisy one. I'll run it a few more times to see. I did notice a little ghosting on the noisy image along the top bar that doesn't seem to appear when I suspend with xochitl.

#97 seems right, though I've actually had it happen where the SSH either does or doesn't respond after the wake. It could just be that I'm fiddling with the power button and re-suspending it without realizing.

[SyntaxBlitz]

ahh this is frustrating, I just got it to render the grey image correctly 15 times in a row, can't seem to reproduce the broken render now. I do think if there's any way to get rm2fb to send a "finished drawing" signal, that's the right way to do this. Otherwise we'll have to cater to the 99th percentile of draw times, which isn't even going to be consistent for one device with one suspend screen.

[Eeems]

ahh this is frustrating, I just got it to render the grey image correctly 15 times in a row, can't seem to reproduce the broken render now. I do think if there's any way to get rm2fb to send a "finished drawing" signal, that's the right way to do this. Otherwise we'll have to cater to the 99th percentile of draw times, which isn't even going to be consistent for one device with one suspend screen.

I've asked for the ability to wait for drawing to finish. Just waiting to see if @ddvk or @raisjn figure out how to make it work properly with the current API

[codeclimate]

Code Climate has analyzed commit d93a0ac and detected 0 issues on this pull request.

View more on Code Climate.

[Eeems]

@SyntaxBlitz, @Witos, or @raisjn would you be able to test this PR to see if it'll work properly on a rM2? I think we might even be able to get away with removing the nanosleep call if EPFrameBuffer::waitForLastUpdate(); actually works under rm2fb

[Eeems]

Thanks @PeterGrace for testing!