black screen on many SDL1.x apps since 3.18.4

[joolswills]

I noticed with the latest kernel / firmware via the raspbian package that most/all of the SDL1.x based emulators had stopped working and were outputting a black screen.

using rpi-update and https://github.com/Hexxeh/rpi-firmware/commits/master repository, I have traced it back to Hexxeh/rpi-firmware@a171d73 (9b068fe on this repository).

It all seems to work prior to the 3.18.4 changeset

Not sure how the other repository updates from yours, but it's all binaries so I can't really see what has changed anyway.

I can provide an example binary if needed.

[joolswills]

just to confirm

rpi-update a171d73 - broken sdl output from most emulators (for example lots of the emulators shipped with retropie)
rpi-update 9ae54e3 - all working fine

[joolswills]

here is an example binary:

http://downloads.petrockblock.com/retropiebinaries/emulators/fbzx.tar.gz

requires the libraries installed by libsdl1.2-dev

(press escape twice to exit)

source is here

http://downloads.petrockblock.com/retropiearchives/fbzx-2.10.0.tar.bz2

this seems to affect all the sdl1.x emulators I have tried so far that were working fine. Am running them directly from the console/on the framebuffer - not via X. They don't crash - as sound can be heard, and it's possible to exit.

[popcornmix]

Nothing jumps out from that commit.
I'll try and reproduce...

[popcornmix]

Yes, can reproduce. It's a firmware (start.elf) change. Just bisecting...

[joolswills]

great. thanks :)

[davidallansson]

Thanks :)

[popcornmix]

Not a fix, but a workaround. Run:

fbset -xres 640 -yres 480 -vxres 640 -vyres 480
./fbzx

and framebuffer works. Not sure why yet...

[davidallansson]

Yep, worked. Getting a picture now. Thanks for a fast workaround :)

[popcornmix]

I can't find anything wrong on the firmware side. The framebuffer seems functional.
E.g. while fbzx is sitting there with a blank screen ssh in and run:

cp keymap.bmp /dev/fb0

And you'll see the spectrum keyboard on the screen (not quite right, as the bit depth is wrong, but recognisable).

So, I don't believe its a firmware issue - just the slight timing change in that version of the firmware is exposing an application or library bug elsewhere.

Now I'm not 100% certain of this, but I can't find any evidence that the firmware or framebuffer kernel driver is doing something wrong.

Are you sure the emulator is attempting to write to the framebuffer?

[davidallansson]

I wrote a simple application where i used SDL to put som pixels out and fipped the buffers with SDL_Flip(). Same issue, it was all black. So i don't think it's related to the emulators.

[popcornmix]

The SDL test app may be useful - can you provide it?

[davidallansson]

Not at hand at this time but this example would do the same. http://friedspace.com/SDLTest.c
gcc sdl-config --cflags --libs SDLTest.c -o SDLTest

[joolswills]

sdl1.x has always worked horribly with the pi, and has been incredibly fussy in regards to params, but it did work for the most part with the right resolution/and a swsurface, or could be made to. this change, even if unknown has broken virtually every emulator/sdl app that did work before :/

I can give you many other example binaries+source if you need it. from scummvm to dosbox.

Unfortunately for me, as a maintainer of retropie, users are now realising lots of things don't work that once did :/

Your bisecting of the changes didn't show up a specific change that broke anything ?

Of course, the best fix would be to make sdl1.x properly pi compatible and ship it in raspbian. But this regression is likely to cause some problems if it can't be fixed.

I hope some fix can be found anyway. I would take a look at sdl1.x myself if I had some more free time.

[popcornmix]

The bisect identified a firmware commit that causes the heap to allocate from the top end rather than bottom end. However the allocation triggered by the framebuffer resize returns successfully and the framebuffer seems usable (e.g. when copying data into it).

So it's not something obvious. Possibly the bug is in libsdl rather than the firmware.
I suspect it may need building sdl from source and adding logging to work out exactly what is going wrong, but that may take a few days.

If you are aware of what specifically is failing (e.g. do any SDL calls return errors when the display is not working), that may help narrow down the issue.

[joolswills]

My own personal experience of programming with SDL is very basic, but given some free time I can try and come up with something. I suspect more users will come forward with more experience with SDL than me (eg @davidallansson)

SDL1.x was always easy to crash on the pi. I believe most of the blame is with the old SDL and the way it uses the framebuffer, but it did sort of work if you didn't use some options.

I'd be interested in a firmware blob that had the previous behaviour just to incorporate temporarily into retropie until a proper fix is found (either via an SDL fix, or firmware). Would that be possible ? How tied together are the firmware files vs kernel - could we for example overwrite this firmware file on our images, and still have it working pi and pi2 systems or is the change required?

thanks for the feedback and looking into this so far btw.