4.0-rc2 images are available for testing.
-
Thanks I'll have a look when I get chance . I was in configuration then all retroarch cfg , was able to set overlays on but when I clicked on the next option down to select an overly is when I encountered the problem . But if they need installing first then I must have missed something, so hopefully that's it
-
@BuZz said in 4.0-rc1 images are available for testing.:
4.0-rc1 is released - see first post in thread.
Is there any additional tweaks to the xboxdrv that need testing or will we need to use the xpad driver steps for the coming GA?
-
@Riverstorm you may well need to use the xpad driver if xboxdrv isn't working. the built in kernel xpad driver should work with 360 controllers, although the led flashes (upstream kernel config change fixes it in the next raspberry pi kernel update)
To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first
-
@BuZz said in 4.0-rc1 images are available for testing.:
@Riverstorm you may well need to use the xpad driver if xboxdrv isn't working. the built in kernel xpad driver should work with 360 controllers, although the led flashes (upstream kernel config change fixes it in the next raspberry pi kernel update)
Ok that sounds good. Would the kernel update be announced here on the forums anywhere or is there a good link to watch for that enhancement?
What I really liked about the xboxdrv is the values are consistent on both wired and wireless. If I remember correctly switching back to the xpad driver several inputs in MAME need tweaked as the values are all different and most of the emulators weren't setup to support joysticks out of the box. Except lr-mame2003 I think Dank added joystick support by default.
-
https://github.com/raspberrypi/firmware
https://github.com/raspberrypi/linuxupdates hit the firmware repo first, and gets packaged later.
To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first
-
@BuZz said in 4.0-rc1 images are available for testing.:
https://github.com/raspberrypi/firmware
https://github.com/raspberrypi/linuxupdates hit the firmware repo first, and gets packaged later.
Thanks Buzz, I will keep an eye out. Sorry one last question will the xboxdrv be phased out in favor of the xpad driver on future releases?
-
I don't know - depends on xboxdrv development vs kernel xpad features
To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first
-
@BuZz said in 4.0-rc1 images are available for testing.:
I don't know - depends on xboxdrv development vs kernel xpad features
Ok, that sounds good. If you need a tester for any additional changes to the xboxdrv just let me know as I do use them regularly and willing to troubleshoot whatever I can. :)
-
@BuZz thanks for all your hard work - just tried 4.0-rc1, really happy with this version and just have 1 note/1 minor issue (which I don't think should stop the release of 4.0 in any way):
1- I'm trying to get all 3 ES+ kodi + lxde/desktop running. When the RetroPie script has installed lxde, even after rebooting, many commands fail to run. This is because the startx command needs to be called for the desktop to finish setting up its thing -- and this took me a while to figure out: could this be documented clearly within the script (e.g. popup asking you to make the call), or just get the script to force the command after the installation process?
2- The new ability to autostart kodi is something I've wanted for a while, so thanks for that, however the exit option fails to return to emulationstation (just kills kodi and turns my tv off!). I've seen this thread but it looks like the autostart does call kodi rather than kodi-standalone, so am stuck on this one...
I'm also using a PS3 bluetooth controller and that all worked fine.
-
1 - LXDE - when you install lxde it installs an entry in Ports for launching it (Did you install it from the raspbian tools menu?).startx is mentioned on the wiki in the FAQ.
2 - are you using CEC ? that may be set to turn off screen on exit - you can change that in Kodi. I launch Kodi before ES on my setups and they exit fine to ES.
-
@BuZz thanks for the quick reply!!
2- bingo, it was due to the CEC adaptor settings! Feel sheepish after realising that it was a kodi rather than retropie issue and seeing similar mentions in kodi forums, so really thanks a lot for answering anyway!
All as good as it has ever been on my pi now with 4rc1 :)
-
There are some glitches with the PS4 controller in RC1. The hotkeys don't work anymore after updating it. I checked the config files and they are like how I configurated them.
-
Nothing has changed in RetroPie regarding PS4 controllers. Are you using ds4drv or were you using the kernel driver (assuming it works out of the box with the kernel). The only thing that may have changed is the Kernel version in the image (which we do not maintain - it is Raspbian Lite with RetroPie installed on top).
You could try installed ds4drv if you haven't already - https://github.com/chrippa/ds4drv
-
Only thing I would note is that the lr-handy binary core that's included is a bit out of date. Specifically, it isn't able to load headerless roms (which includes the entire "no-intro" set).
A rebuild from source grabs the latest lr-handy code, and things work fine after that. I'm not sure who builds/maintains those official binaries, but this would be one less thing for newbies to struggle through.
-
the lr-handy binary was rebuilt on the 20th July - so it should have those changes and they should be included in the image.
-
Looks like I installed 4.0 on the 19th of July, soooooo you got me. :)
-
Hi,
I've been testing 4.0 RC1 and came across a weird situation where I could not get my retropie controller configurations to update/save. It seemed to affect my ability to save Retroarch from within several different emulators that I tested too. After a while I started poking around the file system and noticed that "/opt/retropie/configs/all" was owned by root:root, while the rest of /opt/retropie/configs/* was owned by pi:pi.
After chowning /opt/retropie/configs/all and it's subfiles/folders to pi:pi it looks like my retroarch config changes are now being saved normally from within RGUI.
Is there a bug somewhere which could cause this directory to become incorrectly chowned? I had done some some updates via the setup script, etc.
-
I recall perhaps an old bug, but I don't know of any currently. there were some bugs with config ownership with files in there, but the folder is chowned on launch of retropie-setup currently so it should be ok. There shouldn't be any code that would chown it incorrectly - but there may have been an earlier case where it was created incorrectly.
-
@BuZz
Thanks for the response. My install is new (2 days old), based on the posted RC1 image. I'm confident I haven't executed any chown commands manually, (meaning: I'm sure it wasn't end user generated ;) ). If I notice the issue reoccur, I'll try and note what across or options i executed. The only stuff I'd done was via the setup script previously, including a script update and a packages update (both raspian and RetroPie). I could enable some auditing via auditd or shell history/trap profile.d scripting and try and capture how it occurred if it crops up again.Cheers
-
Did you launch retropie-setup script manually at all ? eg from a root shell. If it was run from root account rather than via sudo it could mess with the permissions for example. I should put some protection in against this perhaps.
Can't see anything in the code that would cause it currently (had a quick grep). But it's possible there is a bug somewhere (there are always bugs!) :)
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.