Raspberry pi 4

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!

karius1982

@Rascas fake o not fake , but retroarch works, i've also tried it works, attached screenshot testing raspbian with retroarch+yabause (saturn)...

mitu

@karius1982 Can you run retroarch --features and post the output ?

karius1982

@mitu ok

pi@raspberrypi:~ $ retroarch --features

Features:
  LibretroDB:		LibretroDB support: yes
  Command:		Command interface support: yes
  Network Command:		Network Command interface support: yes
  SDL:		SDL input/audio/video drivers: no
  SDL2:		SDL2 input/audio/video drivers: yes
  X11:		X11 input/video drivers: yes
  wayland:		Wayland input/video drivers: yes
  Threads:		Threading support: yes
  Vulkan:		Vulkan video driver: no
  OpenGL:		OpenGL   video driver support: yes
  OpenGL ES:		OpenGLES video driver support: yes
  XVideo:		Video driver: yes
  UDEV:		UDEV/EVDEV input driver support: yes
  EGL:		Video context driver: yes
  KMS:		Video context driver: yes
  OpenVG:		Video context driver: no
  CoreAudio:		Audio driver: no
  ALSA:		Audio driver: yes
  OSS:		Audio driver: no
  Jack:		Audio driver: yes
  RSound:		Audio driver: no
  RoarAudio:		Audio driver: no
  PulseAudio:		Audio driver: yes
  DirectSound:		Audio driver: no
  WASAPI:		Audio driver: no
  XAudio2:		Audio driver: no
  OpenAL:		Audio driver: yes
  OpenSL:		Audio driver: no
  7zip:		7zip extraction support: yes
  zlib:		.zip extraction support: yes
  External:		External filter and plugin support: yes
  Cg:		Fragment/vertex shader driver: no
  GLSL:		Fragment/vertex shader driver: yes
  HLSL:		Fragment/vertex shader driver: yes
  libxml2:		libxml2 XML parsing: yes
  SDL_image:		SDL_image image loading: no
  rpng:		PNG image loading/encoding: yes
  rjpeg:		JPEG image loading: yes
  Dynamic:		Dynamic run-time loading of libretro library: yes
  FFmpeg:		On-the-fly recording of gameplay with libavcodec: yes
  FreeType:		TTF font rendering driver: yes
  CoreText:		TTF font rendering driver (for OSX and/or iOS): no
  Netplay:		Peer-to-peer netplay: yes
  Python:		Script support in shaders: no
  Libusb:		Libusb support: yes
  Cocoa:		Cocoa UI companion support (for OSX and/or iOS): no
  Qt:		Qt UI companion support: yes
  AVFoundation:		Camera driver: no
  Video4Linux2:		Camera driver: yes

LiveFreeDead

@karius1982
Thank you, showing RetroArch working is 1/4 of the battle already won for RetroPie being at least at a stage that it will be able to be worked on by more devs than us all stuck waiting for the core OS devs to do their magic compiling new drivers, optimizations and updates, once the OS is ready for RetroArch in the mean time the Emulation Core coders can start on that side of things too.

Good luck everyone and I hope you have a speedy delivery of your Pi's, I ordered day 1 and it's since been pushed back to Aug 4th for me :( I guess the 4gb versions weren't the main batch for release.

Rascas

Yep, my mistake, I am sorry, it looks fine after all. I wasn't expecting that retroarch would run that good, without optimizations. Still not great but it will be better for sure.

marine88

I think the future will be good for the next revision this one just get very hot!