Raspberry pi 4

[aatheronb]

I wasn’t asking for a RetroPie test just some emulators

[mitu]

@aatheronb Sure, you can install the new Raspbian on your Pi4 and then manually compile the emulators - but you'll have to know how to do it, since the RetroPie scripts will probably not work.

[BuZz]

Just to mention I have already spent a number of hours making changes in the last 2 days (not just for RPI 4 but for buster support - even before I got the rpi4). It's not a quick fix. And there is limited information out there. Eg. Currently I can only get a black screen with the legacy driver on the rpi4. Maybe it's not really supported. For the newer driver we need to do a lot of work to get everything working. I was hoping to use the legacy driver as a stop gap, but it's early days.

[mitu]

@BuZz Based on the developers' comments, looks like the fkms driver might be better going forward. I think it's enabled by default in the config for Pi4 in the new Buster image.

[BuZz]

@mitu yep. We will be using that. I was just hopeful we could use the old driver to get stuff working in the meantime. @psyke83 and @gizmo98 already have done some work for the Kms driver which is useful, but a lot of emulators will need changes.

[mitu]

@BuZz Time for a RP 5 tag :).

[BuZz]

@mitu you might have to do that. I'll be retired for sure ;-)

[mitu]

I gave the image a spin this evening and it seems to work fine. Updated ES and scraping from ScreenScraper works again. Started a few games (NES/Arcade/N64/ZXSpectrum) and there's no issue.

I paired my DS4 without any problems, re-connected fine after a couple of reboots.

One thing about the default config.txt - I remember the discussion about overscan_scale not being needed, it came up when Kodi 18 first got the RC and also later regarding steamlink. The default config.txt still has the overscan_scale=1 at the bottom - shouldn't we disable it ?

I'll give it a bit more testing tomorrow.

[BuZz]

@mitu it's still needed for emulation station and other things on displays that require overscan. If we disable it we will get lots of people saying emulation station goes off the screen. It's required on two of my displays.

[dr_dre]

Ive had to add hdmi_enable_4k=1
to config.txt witk kodi to get more then just a grey screen.. maybe its related. !!

[psyke83]

@mitu

Correct me if I'm wrong, but I'm fairly certain that both Kodi and steamlink implemented workarounds to retain compatibility with overscan_scale. I vaguely recall it being mentioned that it may increase latency, though, so having a way to disable it might be handy...

[mitu]

@psyke83 You're right - I think it was a firmware update that was released which fixed this for Kodi and for steamlink you know better.

[LiveFreeDead]

@aatheronb

[Rascas]

@LiveFreeDead Man, that video is fake, please don't publish something that you aren't sure if it is fake or not.

[Rascas]

@mitu What image are you talking about ? About the overscan_scale, yes it was fixed in firmware sometime ago, it is included in latest Raspbian versions.

@BuZz I am pretty busy this days, I didn't received my RPi 4 yet, but I "played" a bit with one today, and from what I saw and read, despite the legacy driver (aka as broadcom proprietary drivers) still works for some parts, like h264 hw video decoding and some opengl es 2.0 stuff, it is buggy and the intention from the RPi Foundation is to abandon it completely and use the opensource video driver (mesa drivers) instead. For example, the legacy driver doesn't support the new h265 decoder. So probably you will have to develop an independent image / scripts for RPi 4, using the opensource drivers or migrate everything done in the past to the opensource driver. I believe that leaving the older RPi stuff like it is for now, and start working on RPi 4 image / scripts only on opensource driver will be easier.

[BuZz]

@Rascas thanks for the info.

yeah. Actually that sounds a lot like our plan. Legacy driver could be a stopover although I've had some issues with it so far but I've not really done any debugging. Just added some buster support to the build system etc. @psyke83 has done some work with support for fkms driver etc.

I'm going to be releasing RetroPie 4.5 before we do any RPI 4 image. Which may be the final Stretch based RetroPie series.

[LiveFreeDead]

@Rascas It's not fake, look at his other videos, he shows it isn't fake:

w w w . youtube . com/watch?v=BsihdHbJMc8

Don't want to post more videos inline, but he enjoys everyone calling his testing fake. I can't say he doesn't have a Pi 3b+ nearby doing the work instead, but he has a Pi 4 so no need to say fake, it was the only one I found that did more than boot to desktop or try to play videos or use youtube, that is why I shared it, I hope it isn't fake, he played with PPSSPP as his newest video. If I am wrong I am sorry to waste your time. I guess we'll have to wait until someone can first hand respond with what it does for them.

[Jste84]

@BuZz said in Raspberry pi 4:

@Rascas thanks for the info.

yeah. Actually that sounds a lot like our plan. Legacy driver could be a stopover although I've had some issues with it so far but I've not really done any debugging. Just added some buster support to the build system etc. @psyke83 has done some work with support for fkms driver etc.

I'm going to be releasing RetroPie 4.5 before we do any RPI 4 image. Which may be the final Stretch based RetroPie series.

Massive respect for the work that you do, can I ask what's made you decide to release 4.5 first?

Is it purely because of the time spent on 4.5? Is there any concern that you build 4.5 and some of the updates don't work on the pi 4? Or do you feel that the changes in 4.5 will mean the 4 image will be better as a result?

Looking forward to both, just curious as to how you make a decision like that. 👍

[BuZz]

@Jste84 4.5 is ready. RPI4 support is only just started. RetroPie doesn't work on the RPI4 yet.

[marine88]

we need to wwait is very green board yet!