Selecting RETROPI SETTINGS causes Black screen

BuZz

@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.

Rascas

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.

BuZz

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

BuZz

Made a few minor updates to the script above.

Rascas

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.

BuZz

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.

BuZz

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.

BuZz

@Rascas While on the subject of framebuffer depth - looks like 32 is the best choice now anyway - https://github.com/raspberrypi/firmware/issues/685

BuZz

@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.

BuZz

@Rascas also just FYI, framebuffer depth is now 32bit by default. https://github.com/raspberrypi/firmware/issues/685

Rascas

@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.

Morphy

Hi I have a very similar issue however I'm not using Kodi. For me it seems like the display sleeps but only for the RP scripts and other shell options. Emulationstation displays ok however if I enter a script the screen is blank. Also when I launch a game I dont see the press any key to configure menu either. When I connect a keyboard and press a key it appears again. The controllers I use dont wake it however. What is causing this and how do I change it please?

BuZz

@Morphy https://retropie.org.uk/forum/topic/7747/finally-got-everything-up-and-running-still-2-minor-issues/3

Morphy

@BuZz said in Selecting RETROPI SETTINGS causes Black screen:

@Morphy https://retropie.org.uk/forum/topic/7747/finally-got-everything-up-and-running-still-2-minor-issues/3

Thanks however I don't have kodi installed on my RP installation?

BuZz

@Morphy I missed that - start a new topic after reading https://retropie.org.uk/forum/topic/3/read-this-first and I will advise.

I have no details about your set-up.

Rascas

@BuZz sorry for the necro, is there a problem if we change this for Kodi 18, to instead of just saving the bitdepth, to save everything (including the resolution) and restore it back at exit ? That would be usefull for us to save some memory from the framebuffer when Kodi is running, since this new version can consume more than the default 256MB. You have the current Kodi 18 start script here if you need more info:
https://github.com/PIPplware/xbmc/blob/leia_new/tools/Linux/kodi.sh.in
Thanks

BuZz

@Rascas May be my memory but I thought we already saved everything ?

Rascas

@BuZz Ah yes, you are right, I was confusing 2 different fixes ... Anyway, there are some improvements that we can do for Kodi 18, when it approaches the final/stable version I will talk to you.