dispmanx sdl

[joolswills]

continuing on from https://github.com/petrockblog/RetroPie-Setup/issues/450 and vanfanel/SDL12-kms-dispmanx#5

regarding dispmanx SDL - https://github.com/vanfanel/SDL12-kms-dispmanx

I don't have a great deal of knowledge about which emulators work better with this SDL and which don't - but if the case is that some stuff doesn't work with it, we should not install it with a /usr but instead install it in supplementary and link against it as needed (or force the libraries to be loaded from there - I believe this was how it was used before ?)

Are you able to fill me in a bit about this @petrockblog ?

[joolswills]

It is in the experimental section of course, so I guess there are known issues.

[joolswills]

Another thing I have just spotted is that dgen seems to be set up to statically link. If raspbian SDL is installed when building dgen, it gives a horrible flashing display (although seems to run smoothly, but that could be a trick of the strobe!). Installing SDL dispmanx won't help until it is rebuild. so dgen definitely benefits from it.

[joolswills]

the flashing is fixed with "bool_doublebuffer = no" in dgenrc when built with raspbian SDL. Seems to run nice and smooth too, so maybe dispmanx isn't needed. going to build against dispmanx sdl again and test.

[joolswills]

dgen on my tv at least seems smoother without the dispmanx sdl. It just needs that config change which I will do.

[petrockblog]

As far as I remember dispmanx was originally introduced to enhance the graphics performance of various emulators. However, in my opinion we could remove dispmanx if we get the impression that things are working more reliable and can be kept simpler then.

[joolswills]

It's possible it could be of benefit to some people but it certainly needs some more testing. I made a mistake earlier in regards to dgen statically linking. Just that the two SDL libraries sit in different places and it confused me. debians libs sit in /usr/lib/arm-linux-gnueabihf and installing the SDL from source with dispmanx causes them to go to /usr/lib/ yet the sdl-configs overwrite each other. Probably not a good idea to overwrite the debian packages with other files.

We have a few options to clean this up

A) ignore it for now :)
B) turn the source SDL with dispmanx into a debian package that replaces the debian one completely. I could base this on the current debian package and apply the dispmanx changes. Might still conflict though and we would need to maintain it etc (could be work....)
C) change the dispmanx SDL to install to /opt/retropie/supplementary - and see if we can force stuff to work with it alongside the debian one (I need to experiment).

If you are happy you can leave it with me and I'll come up with a solution that hopefully works. I'll probably look at the debian package and installing from source. the debian package would be nice and easy if we could just have users download a deb and things worked without being recompiled..

[petrockblog]

Creating a Debian package and maintaining it leads to continuous support work for that and we should try to avoid that. I would vote for option C), but I leave this choice to to you.

[joolswills]

yeh, I'm leaning towards C also. And it would be nice if we can independently have a switch for "which emulators" should use it (without recompiling). I'll let you know how I get on :)

[joolswills]

got a solution. we build everything against the debian sdl, but we point stuff to the dispmanx as needed. just a line with the binary path in /opt/retropie/configs/all/dispmanx and it will use that library first.

[petrockblog]

I like that solution.

[joolswills]

the config file now uses key="value" config and is "sourced" by runcommand. It also uses only the basename of the binary.

See these commits
petrockblog@cf6328c
petrockblog@32bb6a8

[joolswills]

I have added a configuration utility now that allows user to enable/disable per module (if they have the required functions). currently only dgen has support, but will be easy to add support for other emulators now.