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.

[popcornmix]

If there's no progress tomorrow I'll make a custom firmware that reverts the heap commit.
It will introduce an issue where h.264 decode doesn't work when gpu_mem=256 (that was the reason for the heap inversion), but I suspect that won't be a big issue for you.

[joolswills]

Thanks - much appreciated. I hope you get paid for this - and if you do, then you still have a more interesting job than me - pi hacking for a living is a dreamjob no ? :D

Cheers!

[pssc]

Hi, all

I think this is todo with the base address of the frame buffer changing on mode changes which according to the linux spec for a fbdevice it possibly shouldn’t?, I have patched my SDL-1.2.15 version to cope with this. know doubt this will have been aggravated by allocating from the heap differently.
(it used to happen if you changed mode to multiple to multiple different resolutions that sometimes the base address changed).

https://www.kernel.org/doc/Documentation/fb/internals.txt

1. Outside the kernel (user space)

• struct fb_fix_screeninfo

  Device independent unchangeable information about a frame buffer device and
  a specific video mode. This can be obtained using the FBIOGET_FSCREENINFO
  ioctl.
  ....

On a mode change on the Pi the FIXSCREEN info can change, including the base address of the bufferer and offsets stuffing up the Flips etc,

My patched SDL is here it has a number of fixes for the frame buffer and HW double buffering specifically around the Pi, making it more robust in general and coping with extended key codes better.
https://github.com/pssc/squeezeplay/blob/public/7.8/src/SDL-1.2.15/src/video/fbcon/SDL_fbvideo.c
/* Get the fixed information about the console hardware.
This is necessary since finfo.line_length changes.
and in case RPI the frame buffer offsets and length change
*/
if ( ioctl(console_fd, FBIOGET_FSCREENINFO, &finfo) < 0 ) {
SDL_SetError("Couldn't get console hardware info");
return(NULL);
}

Having reread all the docs and code I am more inclined to believe this is an incorrect assumption in the original SDL fbcon driver. As 'unchangeable information about a frame buffer device and
a _specific video mode_' had been interpreted as this info will never change, which Is a trap I also fell into on my first reading and is the assumption the original code makes.

Thanks.

Phill.

[pelwell]

That makes sense. One of the side effects of allocating from the top of the heap is that resizing a block is more likely to cause it to move.

[davidallansson]

I recompiled SDL 1.2.15 with @pssc 's patch and then tested to recompile dosbox in retropie. Works fine what i can see :)

[joolswills]

Excellent. I guess retropie could include a modified SDL, but it would be better if this could be sorted in the Raspbian sdl packages - so SDL1.x will work for all. A small patch added to the package should work nicely. I have no idea who should be contacted about that though.

I'm assuming there is no way to have a fixed base address for the framebuffer as it is dependent on video mode etc ?

@pssc thanks for your changes / info - do you have a diff against the vanilla SDL for your changes (either as a single patch or a set of patches for different fixes)

[popcornmix]

The only way to have a fixed base address for the framebuffer is to always allocate a worst case framebuffer.
But what is that? 1920x1200x32bpp? But you can also have double the virtual height for page flipping. And in fact you may choose to triple buffer or more.
This would just mean megabytes of GPU memory is sitting unused most of the time.

I feel this needs to be fixed in SDL. Can you submit a bug report to libsdl, just to see if they agree with the patch:
https://bugzilla.libsdl.org/

It would be interesting to determine if the same problem exists in SDL 2.0.

It's also worth creating a thread here: http://www.raspberrypi.org/forums/viewforum.php?f=66
We need to persuade plugwash to add the patch to raspbian, but that will be easier if libsdl acknowledge the patch is good.

[joolswills]

@pssc as the author of the fixes is that something you would be happy to do ?

[pssc]

More than happy to work up the patches(this may be after the weekend), and submit ,we might be able get them accepted in debian/raspbrain , but the answer to bugs in sdl 1.2 is use 2.0 officially (no updates to 1.2 for a couple of years)

I will post the patches here first for testing by those interested.

I am unlikely to recode against 2.0 in the short term myself. I am bogged down looking at a Alsa usb /SPI sound issues on the Pi atm. So I can make a release.

[joolswills]

ok thanks. in the meantime I will have to ship some custom SDL libraries with retropie.

I'm sure the SDL devs will say to use SDL2, but a lot of existing software still uses SDL1.x, even actively developed software (and adding SDL2 to things like scummvm which is a WIP has been some work from reading through the pull request/discussion lists)

thanks.

[joolswills]

I created a diff from your changes minus a couple of whitespace changes (where you had fixed up some original indentation that was wrong) - http://malus.exotica.org.uk/~buzz/sdl-rpi.diff

Will give it a test. thanks. (Am creating a new sdl package based on the wheezy one but including these changes - I'll provide a link once built/tested). I'll bump the version to 1.2.15-6rpi or something)

thanks again for doing the fixes.

[joolswills]

Updated debian packages here - (including source package)

http://malus.exotica.org.uk/~buzz/pi/sdl/

[vanfanel]

If you are going for a patch that would "fix" SDL1.x on the Pi, would you guys please include an small fix to the fbdev backend that would make double-buffering work as intended?
In src/video/fbcon/SDL_fbvideo.c, the function FB_WaitVBL() should look like this:

static void FB_WaitVBL(_THIS)
{
        ioctl(console_fd, FBIO_WAITFORVSYNC, 0);
        return;
}

The ioctl is on main kernel years ago, but no one cared to do this little fix...

[vanfanel]

@asb: the X11 backend will always have tearing. Trying to patch the X11 backend to reduce it is futile.
@joolswills : well done! 👍

[joolswills]

I did some more work on sdl, based on the work vanfanel did (thanks) for dispmanx.

http://www.raspberrypi.org/forums/viewtopic.php?f=38&t=99822&p=692525&hilit=sdl#p692525

[sneakernets]

Thanks @joolswills for this!

[joolswills]

welcome :) I guess I should close the ticket now as it wasn't a firmware issue - thanks all.

[popcornmix]

The libsdl package in raspbian should now include the fixes from:
https://github.com/RetroPie/sdl1/commits/rpi

sudo apt-get update && sudo apt-get upgrade

should fix issues with sdl apps.

[joolswills]

Thanks :)

[vanfanel]

Thanks, popcornmix! It was needed!
What about integrating my SDL 1.2.x dispmanx driver too?
https://github.com/vanfanel/SDL-1.2.15-raspberrypi/blob/master/src/video/dispmanx/SDL_dispmanxvideo.c

Works pretty well, it even has an advanced non-blocking triple buffering mechanism with very good performance.
Integrating in in Raspbian SDL would save me from having to manually hack-in dispmanx support in SDL games.

[popcornmix]

Ping @XECDesign about @vanfanel's suggestion.

[joolswills]

https://github.com/RetroPie/sdl1/commits/rpi includes the dispmanx code also (based on yours with some changes). it uses an env variable to switch so best of both worlds.

[joolswills]

aah sorry - I see this is a new sdl driver ? interesting.

[popcornmix]

@joolswills I guess the first question is does @vanfanel's sdl driver work well for you?

[joolswills]

I've not tried this new code - but it sounds good so I will certainly give it a try. thanks @vanfanel

[XECDesign]

Sure. Is it best to have both sets of patches or do things need to be modified for both of these to work together?

[joolswills]

the SDL1 at the RetroPie project has fixes for the framebuffer output code + some dispmanx code based on work Vanfanel did some years ago. It still defaults to framebuffer, but can be switched to use the dispmanx code with an env variable. I guess replacing that code with his newer dispmanx code, but keeping the framebuffer support would be good.

[XECDesign]

So it sounds like I need the framebuffer fixes, separate from the dispmanx code, and then a dispmanx driver on its own? Or just take both sets of patches as they are? If it's the former, I think it's best if someone would email me the patch that they want applied (serge at the obvious address dot org).

[joolswills]

I can look at combing functionality and giving the new dispmanx code a test (we would use it in retropie if it works nicely - which I'm sure it does), and then give you a couple of patchsets ?

[XECDesign]

Sure, that would work. Thank you.

[vanfanel]

@joolswillis: I've updated the new dispmanx driver with my name on it. If you do the patches and send them, use the latest SDL_dispmanxvideo.c.

[sneakernets]

This is a great development, especially for us in the Doom community!
SDL2 will be equally as challenging to handle, as I have to use special versions of those as well...