@mitu Probably for nothing, but Who knows...

@thedatacereal Glad to help!

There is another driver project for ILI9341 based SPI displays https://github.com/juj/fbcp-ili9341 that you can try, if you're still working on the project. That one is a full standalone solution that does not utilize modprobe or the kernel SPI driver. Installation instructions are at https://github.com/juj/fbcp-ili9341#building-and-running

You probably were able to figure this one out since it has been quite some time, though just wanted to reply for anyone stumbling to this; the mixed up colors seem to be an artifact of the SPI bus bandwidth limitations of the ILI9486 controller chip on the display. If the display is driven too fast that the controller simply cannot handle it, the colors on the whole display can get distorted. There is no way around it.

My ILI9486 has maximum speed of 31.88MHz (31880000), and beyond that the colors get messed up. I posted a comment on the thread you linked to with more information about the observed limits of ILI9486 with a video. With fbcp-ili9341 project I was able to squeeze out some more performance from the ILI9486 compared to the dtoverlay method, but beyond simple retro games, it looks like ILI9486 is definitely not a display controller for fast paced games.

@dankcushions

Thanks for your suggestion. I managed to get every game back to unpixelated by using FTP and deleting mupen64plus.cfg

Second time I’ve had to do that. Any idea why?

It kind of looks like some games reject the default emulator setting that I’ve set (gles2n64) and revert to lr-mupen64plus. I think that because I went into retropie setup>manage main packages>mupen64plus and removed it. Then I went and tried to start a 64 game out of interest. They started, pixelated as there was only one emulator available lr-mupen64plus. Just a thought.

Mostly trying to work out why sometimes it randomly decides that certain games will be pixelated from now on. Cheers.

Strip a broken Nes

Account is removed.

@eggman I think you can force a specific order for the sound cards through configuration, described in this Archlinux wiki page. You just need to know the name of the sound kernel modules loaded, but that's easy - you look in /proc/asound/modules:

pi@retropie:~ $ cat /proc/asound/modules 0 snd_bcm2835

This means the 1st soundcard (index=0) is controlled by the onboard PI sound chip, with the kernel module called snd_bcm2835. Your output will have 2 sound modules loaded, so you can note the name of the USB wireless sound kernel module and create a file ( /etc/modprobe.d/0-sound.conf) with 2 lines:

options snd_bcm2835 index=0 options <NAME_OF_THE_2ND_SOUND_MODULE> index=1

Ideally you can try to replicate the problem - sound routed to the wireless card - then see if applying this configuration fixes the problem.

Please provide some information about your system, as detailed in https://retropie.org.uk/forum/topic/3/read-this-first.

@thelostsoul said in While updating all themes it waits for input "Username for 'https://github.com':":

es-theme-cygnus

it looks like this theme repository doesn't exist anymore. paging @BuZz - guess it can be removed from https://github.com/RetroPie/RetroPie-Setup/blob/06d4418ed485f701ce42f61e9a1777142c0fd946/scriptmodules/supplementary/esthemes.sh ?

after that is done, you could update your setup script and try again.

@tuki_cat very glad it's working! Setting up varying types input devices is not a trivial thing. Thanks for reporting what worked for you.

@tommeesawyer I know this is pretty old thread... I’m about to try 2 xin mo for 4 players plus a ultimatc trackball. Did you have any issues assigning 4 players in emulation station controller setup? All working good with mame and 4 player console games? (ex. Mario kart 64)
Hopin for some insight with this option rather than single player zero delay controllers taking up all 4 USB ports...

@jenny18 a spinner automatically detects as a mouse. You shouldnt have to do anything to get it working. In a mame game you might have to enable spinner/trackball/mouse in the game. A spinner never will detect as a controller.

@stuart2773 Thanks. Yes I already use this site, they have some really good scans.

I think it is definitely related to the cheevos. When I load up RetroArch from the RetroPie menu, the controller is detected instantly like always. When I try to load a game, it takes a long time before detecting. When I disable the cheevos and load up the same game, the controller is recognized instantly too. The strange thing is, it waits like it's connecting to the server, but doesn't pop up my profile being logged in until AFTER it detects my controller. Even then, it's slow popping up the list of earned cheevos for me. I wonder if there's work being done on that side of the system?

@meleu - Anything going on you know of?

@rsn8887 RetroPie doesn't automatically maps the keyboard as a controller - it only saves the gamepad configuration from the configuration you made in Emulationstation. Unless you explicitely map the keyboard in ES, it shouldn't generate any configuration for it.
You can find the saved configurations - one per gamepad configured - in the /opt/retropie/configs/all/retroarch-joypads folder.

Must be a new RA thing, does it do the same without the keyboard plugged in ?

@buzz I figured as much after posting.

Just on idea on the splash screen set-up: right now if the system has a launching.[png|jpg] in the /opt/retropie/config/$system folder, it's shown as splash screen. Can we add also the /home/pi/RetroPie/roms/$system as search path for the launching.[png|jpg] file ? This way copying the ROM folder would copy the launch image and it would make it easier to transfer/backup the launching image ? It can also be something like /home/pi/RetroPie/roms/$system/images/launching or /home/pi/RetroPie/roms/$system/media/launching (which I'd prefer, since scrapers can save information in the media folder).