4.0-rc2 images are available for testing.

BuZz

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

Riverstorm

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

BuZz

https://github.com/raspberrypi/firmware
https://github.com/raspberrypi/linux

updates hit the firmware repo first, and gets packaged later.

Riverstorm

@BuZz said in 4.0-rc1 images are available for testing.:

https://github.com/raspberrypi/firmware
https://github.com/raspberrypi/linux

updates 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?

BuZz

I don't know - depends on xboxdrv development vs kernel xpad features

Riverstorm

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

BennyProfane

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

BuZz

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.

BennyProfane

@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 :)

PetroRie

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.

BuZz

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

bmn001

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.

BuZz

the lr-handy binary was rebuilt on the 20th July - so it should have those changes and they should be included in the image.

bmn001

Looks like I installed 4.0 on the 19th of July, soooooo you got me. :)

felixrising

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.

BuZz

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.

felixrising

@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

BuZz

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!) :)

mauruco

Hello.
I had trouble installing my garsia controller. I searched a bit and found the error on the line 69 in ps3controlle.sh. I left the line 69 + 75 commented and then I was able to install it. I think that after installing the drive ps3 the file "sixad" was created or already existed.
Regards

felixrising

Hi @BuZz,

No, I didn't su to root and run it from there, only via sudo. Probably a good idea to add some [ id -u != pi ] test as you mentioned. Anyway. I'll definitely keep an eye out and help isolate it if I can.

EDIT. I just checked, /opt/retropie/config/all is owned by root again!.

<snip>
pi@retropie:/opt/retropie/configs $ ls -ltrah
total 144K
drwxr-xr-x 7 root root 4.0K May 27 21:43 ..
drwxr-xr-x 2 pi pi 4.0K May 27 21:43 ports
-rw-r--r-- 1 pi pi 26 Aug 8 23:30 bluetooth.cfg
drwxr-xr-x 3 pi pi 4.0K Aug 8 23:43 dreamcast
drwxr-xr-x 35 root root 4.0K Aug 8 23:43 .
drwxr-xr-x 4 root root 4.0K Aug 9 01:13 all
drwxr-xr-x 2 pi pi 4.0K Aug 10 19:00 ngp
drwxr-xr-x 2 pi pi 4.0K Aug 10 19:00 ngpc
drwxr-xr-x 2 pi pi 4.0K Aug 10 19:00 pcengine
</snip>

Cheers & love the project!