how does emulationstation go around the need from drmsetmaster drmdropmaster ?

[mitu]

@joyrider3774 said in how does emulationstation go around the need from drmsetmaster drmdropmaster ?:

i understand that emulation station is not having code for drm / kms explictly but if using SDL2 on a rpi 4 i'm guessing the DRM / KMS backend of SDL2 is used and sdl opens the device, or does it use another backend with the rpi4 ?

No, the DRM/KMS video backend of SDL2 is used on a Pi4. Right now it even uses OpenGL (instead of GLES), since the open source MESA driver supports it.

if not could you point me to the file where the rendering and "other things" get disabled i wonder if the same could be achieved in attract mode.

This is where a game starts, calling window->deinit(), which in turn deactivates the GL renderer.

[joyrider3774]

ok thanks for the info, in theory the same should be achievable with attract but might depend on the libsfml-pi how it handles sound / video etc and if it can be easily temporary deinitted and afterwards reinnited.

PS. attract by default also uses OPENGL in DRM mode, but can be compiled with opengl es as well both seem to work fine when i tested

[joyrider3774]

@mitu author of attract used another way offloading the calls to seperate binary and making sure it has enough rights. Just tested i can run attract again without root and emulators do start

https://github.com/mickelson/attract/commit/6a7ade43656967d038f6e3ab9e1d505da6f00c11

would this mean attract can be added again eventually to experimental packages ?

[mitu]

@joyrider3774 said in how does emulationstation go around the need from drmsetmaster drmdropmaster ?:

would this mean attract can be added again eventually to experimental packages ?

Well, it was never gone, just that it was masked for the Pi4 platform. I'll see what we can do to bring it back for all Pi platforms - including the Pi4.

With the recent changes, it's probably worth testing it on other SBC platforms that might be supporting KMS/DRM.

[joyrider3774]

@mitu when adding compile flags, on rpi building attract you need now to explicitly set USE_MMAL=1 and USE_DRM=1 for it to use mmal hw video decoding and drm backend on the pi4 (or at least have that option) when having build ffmpeg with mmal support, also don't forget to compile that helper program i linked in previous message or no emulators can start when running as the pi user. It's in attract/util/linux/drm folder and just needs make and sudo make install.

SFML-PI also needs an explict parameter for building DRM version on pi4

[mitu]

Hm, looking at the changes, it looks like the new DRM support overrides the previous RPI support - this will break support for older/existing models where DRM/KMS is not used (Pi0 - Pi3).

EDIT: or maybe not - will have to test and see.

[joyrider3774]

@mitu it's still possible to compile using old way needs different set of params its documented on github but i have not tried building a version for my rpi 3 it should not break things, only needs different compile parameters on a rpi4 for both sfml pi and attract

[mitu]

@joyrider3774 attractmode should be now installable on the Pi4 again. One deviation from upstream is that the launching script will try and pre-set the video resolution based on the system's current video resolution instead of relying on DRM's detected preferred video mode.

[Clyde]

@mitu I just updated Retropie on my Pi 4 and attract mode is back in the experimental packages. Although I don't use it myself in the forseeable future, thanks for bringing it back!

[mitu]

@Clyde I just added some small changed the the RetroPie scriptmodule, the hard work was done upstream, by the AttractMode developer.