Ubuntu 19.04 issues
Neo-Rio last edited by
The beta is out and the new release of Ubuntu 19.04 is nearly upon us. In case anyone is wondering if Retropie will run on it, the answer is currently no.
Essentially libxbcommon-dev, libusb, libvulkan-dev, libavcodec-dev, libavformat-dev, libavdevice-dev and nvidia-cg-toolkit won’t install.
Dependecies for libsdl and libsdl2-dev get mucked up and a lot of other builds don’t work.
Stick to LTS versions of ubuntu for now
I recently tried the installation on Debian Buster (testing) and it went ok, if you bump the SDL2 version (from 2.0.8 to 2.0.9).
I've not yet updated but will soon. If newer SDL doesn't have dependency issues I can force it for x11, but I'm actually considering disabling our custom SDL for x11 by default. It has only one patch really (PS3 controller one).
You can disable our SDL2 by putting
(I think this is right - can't check right now).
It has only one patch really (PS3 controller one).
And also the patch that supresses the 'unknown scancode...'. .
You can disable our SDL2 by putting own_sdl2="0" in /opt/retropie/configs/all/retropie.cfg
Thanks for the hint, I'll give it a try with the newer Bubuntu, just to see how it behaves.
I'm still trying to find a fix for the 2.0.9 regression (reported a few weeks back), but I've run just a preliminary bisect and I have to confirm which is the offending commit.
@mitu Thanks - will be useful to identify the cause.
Just tried with the beta 19.04 image and it behaved similarly to Buster - once the SDL dependency is solved (either upgrading to 2.0.9 or using the distro's libs), there are no errors during installation.
nvidia-cg-toolkitis installed only if an available version is found in the repositories - there isn't one for 19.04, indeed - and for the other packages I also didn't have any problems. For both distros I compiled some additional packages - PPSSPP, dolphine, attract-mode, mehstation, reicast, dosbox, advmame - without encountering any packages/dependencies errors.
@Neo-Rio did you try with a clean installation or upgraded an existing installation ?
I was using a fresh install of a beta very close to release date.
Now I am using a fresh official release install of 19.04
I had a look for
Since I didn't see any retropie.cfg file in that directory, I created it and added the own_sdl2="0" flag
That's allowed the basic install to complete successfully.
One thing I have noticed though is that MAME2010 in particular just runs a lot slower. It's really dismal performance.
Not sure what - if anything - this distro is doing to cause that.
SF2 used to run full speed. Now the sound is buffering.
@Neo-Rio It depends on the video driver used - do you have HW accelerated OpenGL ?
That’s interesting because 19.04 has better graphics support for AMD graphics, and my system is running an AMD2400G
I would have thought that graphics capabilities would have improved- if anything.
I never had to tweak anything to get 18.04 working, but it looks like I will have to on 19.04
Parabolaralus last edited by
@Neo-Rio Off-Topic: Have you tried running PCSX2 on Ubuntu with that 2400g? Ive been seriously considering upgrading my Phenom for this emu and this was on my list...
Since I didn't see any retropie.cfg file in that directory, I created it and added the own_sdl2="0" flag" Works perfectly in a VM, i might do a clean install later!
I've been uising Xorg, but trying to flip over to Wayland makes no difference. I even installed the hwe package.
It must be some AMD driver problem. Even emulation station seems to judder a little as system logos move left to right.
It's not just mame2010 either, but a whole slew of the default emulators from the basic install are buffering
If you can tell me how to get the log from a session, I'll upload.
For the record, here's my "inxi -Gx" output.
Remember that this is just a system with an AMD 2400G and using built in graphics.
Device-1: AMD Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series]
driver: amdgpu v: kernel bus ID: 08:00.0
Display: x11 server: X.Org 1.20.4 driver: amdgpu resolution: 1024x768~60Hz
OpenGL: renderer: AMD RAVEN (DRM 3.27.0 5.0.0-13-generic LLVM 8.0.0)
v: 4.5 Mesa 19.0.2 direct render: Yes
Also glxinfo -B:
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: AMD RAVEN (DRM 3.27.0, 5.0.0-13-generic, LLVM 8.0.0) (0x15dd)
Video memory: 2048MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 4.5
Max GLES1 profile version: 1.1
Max GLES profile version: 3.2
Memory info (GL_ATI_meminfo):
VBO free memory - total: 1829 MB, largest block: 1829 MB
VBO free aux. memory - total: 3039 MB, largest block: 3039 MB
Texture free memory - total: 1829 MB, largest block: 1829 MB
Texture free aux. memory - total: 3039 MB, largest block: 3039 MB
Renderbuffer free memory - total: 1829 MB, largest block: 1829 MB
Renderbuffer free aux. memory - total: 3039 MB, largest block: 3039 MB
Memory info (GL_NVX_gpu_memory_info):
Dedicated video memory: 2048 MB
Total available memory: 5120 MB
Currently available dedicated video memory: 1829 MB
OpenGL vendor string: X.Org
OpenGL renderer string: AMD RAVEN (DRM 3.27.0, 5.0.0-13-generic, LLVM 8.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.0.2
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.0.2
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.0.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
glxgears works at above 60FPS as well.
Neo-Rio last edited by
Never mind. I am a teapot.
My monitor refresh rate was somehow set to 23Hz in the system settings !
I set it back to 60Hz and everything is back to normal!
dgallina last edited by
Just to add a data point: I did an in-place upgrade of my Ubuntu 18.10 RetroPie install to 19.04 without issue using the suggested config file change above.
Same here. I can't yet reproduce the issues above and I removed all SDL2 dependencies.
I will install a fresh 19.04 in a vm to test though.
Did anyone post a log? Didn't see one but it may save time to see what the fail was on 19.04.
@BuZz I don't think there was anything besides the SDL2 dependency and the other posters confirmed it was working fine once that is fixed.
I don't have the Debian Buster system that exhibited the problems at hand, but for the 19.04 I didn't get any errors during installation. I bumped the SDL2 version in
sdl2.shbefore starting the basic installation.
@mitu I'd like to see the full log from any 2.0.8 SDL install fail as it's working here without bumping the version.