Selecting RETROPI SETTINGS causes Black screen
-
@arealdushbag if you aren't familiar with Linux terminology or what each retropie setting is (retropie has a lot of settings) you can always just post a video or screenshots of the steps you are taking as well.
-
I think this is related to a kernel update. I have the problem on one of my machines (noticed half hour ago) so I will be looking into it.
-
@herb_fargus @markyh444 @BuZz
So the problem was that when I exited Kodi back into emulation station and try to enter into the RetroPI setup script I would not see the menu. I originally configured my retropie to boot to Kodi automatically(first mistake). So I eventually found one of
@markyh444 old forums post about a similar problem. The fix I found from that post was not to auto boot to KODI and boot to emulation station instead. That fixed the problem. I did not mention that I was exiting KODI then trying to launch RetroPI setup SCRIPT. I thought Kodi wouldnt affect me trying to launch that window. -
I've never had Kodi on any of my RetroPie builds, so I dunno how you've found an old post by me about this.
-
I also go to es from kodi. I suspect now a kodi script change or something in tvservice. I'll debug this though.
Also why giving as much information as possible helps, as it gives me a pointer as to how to reproduce and fix it.
-
There wasn't any change in Kodi from some time now, the last one was from some days after the 16.1 release. Although I didn't test the RetroPie 4.X versions yet, I suspect this is because of the old "black screen on exit bug" in Kodi which was never fixed but it has a workaround, which is changing virtual terminals on exit. Can you try to edit /usr/bin/kodi and in the end, change the line
sudo chvt 2
to
sudo chvt 3
-
@Rascas Thanks. I guess some firmware / kernel change has brought it back again - I will test above, and also rolling back kernel/firmware.
I will also test doing
fbset -depth 8; fbset -depth 16
which is what we use in retropie to reset the framebuffer. -
I thought the black screen on exit was a Kodi 15 bug which was fixed in 16 ?
Another thing - your line
tvservice -p
can be problematic on composite set-ups (a user reported it here) - Better would be to save the mode before launching kodi viatvservice -s
and restore the mode afterwards.The
fbset -depth 8
/fbset -depth 16
might work better than switching vts btw as it will work even if already on VT 2. Also no sudo needed.I would also add a 1 second delay after switching mode with tvservice.
-
It wasn't really fixed in the program or firmware, but workarounded in /usr/bin/kodi.
Can you give me an example on how to save and restore with tvservice, in a way that works for any kind of TV / setup ?
I don't remember exactly in what but I think the change of VT is needed because of black screen after exiting Kodi. I think
fbset -depth 8/fbset -depth 16
isn't enough. I will try to test it but only on Monday now, can you please test it also ? -
@Rascas Have done some testing.
Actually it was enough to add a
sleep 1
right after tvservice to fix the problem. I also tested with fbset which works - so I think this would be safer (and reduces the need for a check)sudo tvservice -p >/dev/null 2>&1 sleep 1 fbset -depth 8 fbset -depth 16
but I would also remove the tvservice line altogether - unless you are actually saving the previous mode and restoring it - are we certain Kodi doesn't restore the video mode on exit anyway. Works here to just include the
fbset
lines. -
sudo tvservice -p >/dev/null 2>&1
This is only needed to fix a bug in which, if one uses a different resolution in Kodi than the default TV resolution (or the defined in config.txt), when you exit Kodi, ES stays in the same resolution of the one set in Kodi. -
I put this together based on runcommand code (converted from bash to generic shell) - only had limited testing but should work on composite (as tvservice -p does not work right when using composite out)
#!/bin/sh save_mode() { local status="$(tvservice -s)" if echo "$status" | grep -qE "(PAL|NTSC)"; then MODE_TYPE=$(echo "$status" | grep -oE "(PAL|NTSC)") MODE_INFO=$(echo "$status" | grep -oE "([0-9]+\:[0-9]+)") else MODE_TYPE=$(echo "$status" | grep -oE "(CEA|DMT)") MODE_INFO=$(echo "$status" | grep -oE "\([0-9]+\)" | tr -d '()') fi } restore_mode() { if [ "$MODE_TYPE" = "PAL" ] || [ "$MODE_TYPE" = "NTSC" ]; then tvservice -c "$MODE_TYPE $MODE_INFO" >/dev/null else tvservice -e "$MODE_TYPE $MODE_INFO" >/dev/null fi sleep 1 fbset -depth 8 fbset -depth 16 } save_mode # launch kodi restore_mode
-
Made a few minor updates to the script above.
-
Nice. If the chvt isn't really needed anymore and can be replaced with fbset, I think something like this maybe better:
#!/bin/sh save_mode() { local status="$(tvservice -s)" if echo "$status" | grep -qE "(PAL|NTSC)"; then MODE_TYPE=$(echo "$status" | grep -oE "(PAL|NTSC)") MODE_INFO=$(echo "$status" | grep -oE "([0-9]+\:[0-9]+)") else MODE_TYPE=$(echo "$status" | grep -oE "(CEA|DMT)") MODE_INFO=$(echo "$status" | grep -oE "\([0-9]+\)" | tr -d '()') fi ORIGINAL_DEPTH=`fbset | head -3 | tail -1 | cut -d " " -f 10` } restore_mode() { if [ "$MODE_TYPE" = "PAL" ] || [ "$MODE_TYPE" = "NTSC" ]; then tvservice -c "$MODE_TYPE $MODE_INFO" >/dev/null else tvservice -e "$MODE_TYPE $MODE_INFO" >/dev/null fi sleep 1 fbset -depth 8 > /dev/null 2>&1 fbset -depth $ORIGINAL_DEPTH > /dev/null 2>&1 } save_mode # launch kodi restore_mode
This is because, for example in PiPplware distribution, we use framebuffer_depth=32 which gives better quality image in some cases, like pictures / fotos in Kodi and LXDE/XFCE. Not sure if this gives better image quality in emulators though, probably not.
-
That change looks good. You can probably save and restore the framebuffer width/height too although probably not needed in this case. We do this in runcommand as we allow changing of framebuffer resolution, and need to restore it correctly. We don't actually save the depth as above, so I will change that too.
in the unlikely case that the framebuffer was in 8bit mode first, you would probably need to do
fbset -depth 16; fbset -depth 8
(setting for to another depth to reset it). Although I don't think anyone runs in 8bit by default.Regarding 32 bit quality in emulators - I don't know - perhaps for some that run on the framebuffer - but there were some issues with 32bit in the past but I can't remember exactly what. I don't think this would affect retroarch/sdl2 etc.
-
Also Kodi doesn't use the framebuffer but RPI dispmanx api etc so I wouldn't have thought you need to set framebuffer to 32bit mode for Kodi - for X applications though you would.
-
@Rascas While on the subject of framebuffer depth - looks like 32 is the best choice now anyway - https://github.com/raspberrypi/firmware/issues/685
-
@Rascas any news on this ? More black screen reports have come in. If you are short on time, I might add a fbset workaround to the end of the Kodi launch or ES launch script via RetroPie-Setup.
-
@Rascas also just FYI, framebuffer depth is now 32bit by default. https://github.com/raspberrypi/firmware/issues/685
-
@BuZz yes, I am a bit short on time, I will change kodi launch script when Kodi 17 comes out (it should be this month still) but change it where you see more fit if you want till there.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.