Why is Lakka so complicated to use?


this is not a rant. I would like to understand why there are so many hurdles to overcome to get Lakka running. I use retroarch on switch and I use many other emulation systems on different system. Lakka/Retroarch is among the best of them. But it could even get better. Many friends of mine ask me everyday on how to get Lakka/Retroarch running. Maybe we could make it easier to understand.

  1. ROM folder and adding them to a playlist

I know that I have to add the roms to the rom folder and start adding them. Roms that exist in the database are added to the playlist. If I use “add manually” then the database will be ignored and the roms will be associated to a core.

Wouldn’t it be much easier for everyone if the system folders like “snes”, “mame” or “dreamcast” would already exists? Then all roms ins e.g. snes would be added to a manual playlist for the core “snes” right away. The would be added automatically. Then the user could optionally check this roms against the database and add thumbnails. But this would be really optional.

  1. BIOS management

Why isn’t there a folder called “bios” and not “System” or “core/system” on Switch. Some cores even need there special subfolder. You have to look this up on the internet to understand where and which bios files needs to be there.

A unified bios folder with a checklist with checksum check and a checkmark for “passed” if the correct bios with the correct name exist in this folder would be much more convenient.

  1. Bluetooth controllers

There are not many types of controllers out there that people really use. There is PS3, PS4, XBOX ONE, XBOX 360 which can be connected via USB to get them started.

But why are bluetooth controllers (like 8bitdo) so hard to connect? You even need to use the terminal. Why is this so complicated? Why isn’t there a simple pairing procedure within lakka for 8bitdo or bluetooth in general?

I am really curious if all this is by design and intentional or if someone says: yeah, why not make it easier. Or if these things are technical limitations within lakka.


We could do that, but people have so many different ways of sorting and managing their ROMs that I would rather let people create such folders themselves

There is one though, you must have missed it

Because RetroArch lacks a Bluetooth GUI, there is a bounty for that if you want to contribute by donating to the project

1 Like

regarding the roms folder: I understand that point. But this way many people might not understand that they have to scan for content first after they put the roms in the folders.

And I can not locate the bios folder. People are asking for this in the forum: ROMs & BIOS - Where to Place?

This is the “learning curve” of Lakka and RetroArch, people have to learn and know how it works

You said it in your first message, it’s the “system” folder

1 Like

Is this really the option of the team behind Lakka and Retroarch or just your personal opinion? Because changing this would lead to a better acceptance of lakka. And more attention would help the software and community.

ok, why not name it “bios” then? Without google this would be a dead end for many games. Why not make it easier and therefore better?


I added a request on github for a better roms and bios management https://github.com/libretro/RetroArch/issues/10065

1 Like

No. I like it this way. Others not. That’s life.

RetroArch and Lakka are fairly complex in comparison to stand-alone emulators.
Have you tried them?
Some emulators have preconfigured paths while others let the user decide.
Controls the same.
Some system require BIOS files, some fonts, additional files that are not BIOS files. How would you handle this?
For every core (emulator) separated folders?

Maybe people should begin by reading the docs first: https://docs.libretro.com/

[EDIT] To answer your questions:

You don’t have to add your games to a playlist. You can launch them by Load Content as you do this in many standalone emulators. The playlist is optional.

No, no and … NO. I don’t like unnecessary folders on my system. If i use only SNES and GBA than i don’t want additional folders. I want to organize my roms the way I want. What about NAS? Or having them on a external USB storage?

RetroArch is the official reference frontend for libretro “cores”: applications that include emulators, game engines, and media players. Settings are also unified across cores with advanced features like shaders, netplay, rewinding, and more!

As you can see different emulators need different files. BIOS, firmware, core specific configurations, headers, fonts … I think system is more than appropriate for this kind of things

I don’t have bluetooth controllers, sorry.

1 Like

Posted links to related issues in the issue you created over at https://github.com/libretro/RetroArch/issues/10065

While some may find it difficult to use, RA has come a LONG way in terms of usability than where it was a couple years ago. We just have to keep at it and continue with these incremental improvements.

The Bluetooth bounty is over at https://github.com/libretro/RetroArch/issues/8916

1 Like

I pledged money for the Bluetooth driver and the Dropbox/google drive support for save games.

I know that RA has come a long way in the regard of usability. But it could perform so much better if the very first steps would be easier for everyone.


Like any other software, there’s always some kind of learning curve. Whether it’s Microsoft Office, Photoshop, or RA, there’s always that period of time where you’re getting used to it.

1 Like

Good software is intuitive and easy to use. More advanced features can be hidden behind further options. But I see that there are several issues and bounties to accomplish exactly that.


@MarcTV Ludo and LudOS (http://ludo.libretro.com/) is currently in development and is more in line with the ‘easy to use’ approach. In my opinion its missing only very few but key features, most noticeably controller configuration.

Since i don’t have a github account i want to express my concerns here:

I read through issue #10065 and #3322 and it scares me a bit.

Automatically Scan “Content Directory” may seems a good idea in the first place, but we already have “Automatically add content to playlist” in Settings - File Browser.
I disabled this, because if i want to test a game, a romhack or something similar, i don’t want it added to my playlist.

The same applies to “Automatically Scan “Content Directory””.
What if someone puts the roms in the wrong folder? Cluttered playlists everywhere (Buzz Lightyear meme here :wink: )

I also don’t like the idea of automatically generated system/BIOS folders.
There are some cores, where some games require some additional files.
What if i dont use those games in relation to this cores?
I get empty folders for what?

Maybe i’m a bit of a bean counter, but i think there are so many different ways to organize files.
Everyone has a different preference.
Taking away this option don’t make a software more accessible. That is exactly what we did not need.

Don’t get me wrong. Like you i want to see RetroArch to improve.
But your argument

is b***s***

RetroArch is not Microsoft Paint. Is not even Photoshop.
It is more like the whole Adobe Suite.
And don’t tell me that it’s accessible for noobs.
If it is so, you can transport your workflow to Microsoft Paint as well…

The Adobe Suite for graphic designer is the TOP Product (mostly), but you have to learn it before you can use its full potential.
You must know where to put filters, fonts, brushes…
You have to learn how to make things work, what each individual feature does and so is RetroArch.

Dou you know how many threads in the designer forums are filled from new users not knowing how to follow tutorials, because they don’t take a minute to set up the program?
Same on Microsoft Office support forum. So many questions, why program x is not working like program y.

RetroArch is not a single emulator. It is much more and to use every feature to your liking you have to do some work yourself. You can read the documentation, ask questions on the forum an make suggestions as well, but don’t belive all users see it the same way as you.


  • Having the program force you to use predefined folder structures and the creation of unnecessary empty folders is not accessibility.
  • Filling playlists automatically creates cluttered playlists with unwanted entries
  • The same applies to hide advanced features (we already have this possibility) Hiding too much features leads to unnecessary questions from noobs that they can’t find features they seen elsewhere (Youtube playthrough videos for example)

As @metchebe is pointing out, there are attempts to fulfill the need of a simplistic interface.
But please don’t transform RetroArch in a PICNIC-secure software.
There are too many such things around.


I agree and have used many of these analogies myself. :slight_smile:

We definitely want RetroArch to be as easy to use as possible, but we don’t want to make it harder for power users in the process.

One example of that that’s bothered me ever since it was implemented is the core-picker popup that comes up after you load content. We added it because people thought it was unintuitive to have to load a core before you could load content, but it added an additional step for people that did understand that, and that added step never goes away (unless you load from a playlist, which means I load from history 99%+ of the time in part to avoid it).

RetroArch is definitely weird and doesn’t work like other programs that anyone is used to, but that’s because it works the same everywhere. So, once you learn how RetroArch works, it works the same on consoles, on mobile, on desktop PCs, etc.


“Everything should be made as simple as possible , but no simpler .” --Einstein

I’d say Lakka isn’t “as simple as possible”. My current struggle is managing the overlapping constellation of config files (config/opt/rebinds) at the system-wide/core/directory/rom level to get the behavior I want (sprite-based PS1 games in SD with bilinear filtering, polygonal PS1 games in HD with no bilinear).

Some of the default controls are pretty tedious to fix too, like how Dreamcast leaves the LB/L1 and RB/R1 buttons unbound by default instead of just using them as a 2nd LT/RT. But fixing that broke the twin-stick mode for Virtual On Oratio Tangram because it somehow also broke the binding of the boost buttons, and there is no way to rebind when you’ve turned on twinstick mode. And that’s not even getting into the complete mess that is the default N64 config, which is compounded by the fact that Mupen requires a restart to take config changes.

Even just setting up Playlists is so hard that I ended up rolling my own filename-based playlist builder in Powershell. Works super-well, I can add and delete ROM files and run my playlist-maker and it updates them. When I get it cleaned up I’ll post it to Github.

I’m a developer by trade so I probably should figure out how to build the project so I can properly contribute. Haven’t toughed straight C in decades though.

1 Like

I agree with some of your points - like having empty folders is a bad idea. However, having an option to auto-scan a certain directory (disabled by default) may be not that bad. And, regarding your comparison - while I do agree that we definitely shouldn’t make thing harder for power users, making simple use of the software harder than it should be is just unneccesary gatekeeping.

While i’m not against such a feature, in this thread we talked about nOOb-friendliness and “disabled by default” it is not.
Than we have the same problem as the OP explained.

My point was, that even the simplest solution can’t work if the user is not willing to take the time looking at the features provided.
RetroArch has a lot of features and most of the time it is working out of the box.
But for using more advanced features (and in my opinion the playlist is such a feature) you have to learn how make them work.

Same goes for BIOS or system files.
There are cores working without the need to setting them up and others demanding specific files. (mednafen and higan IIRC)
This is not the design of RetroArch, but of the original emulators.

Making changes needs to be properly considered and most of the time the first idea is not the best :slight_smile:

Why isn’t there a folder called “bios” and not “System” or “core/system” on Switch. Some cores even need there special subfolder. You have to look this up on the internet to understand where and which bios files needs to be there.

you can’t call it ‘BIOS’ because it’s not just ‘BIOS’ files. it’s basically any sort of supplementary file that the given core uses, that can’t/shouldn’t be packaged with it. for example, various MAME cores use the System folder for their ‘samples’ (audio files for sound effects/music/etc).

I agree that Retroarch/Lakka can be complicated to use, but fundamentally it’s powerful software with many different uses, and it’s increasingly difficult to think of quick wins that don’t involve upsetting existing use-cases. i think a big win would be a visual controller binding system, but that’s presumably a lot of work.

i’m surprised that, given its popularity, you don’t see any(?) UX experts or designers contributing their time to retroarch. i think perhaps that’s an indication that the task of wrangling powerful emulation software into a snappy slick thing is non-trivial.

PPSSPP for instance needs all sorts of assets in the system directory, like fonts and such. It’s not just BIOS.

1 Like

I just installed Lakka on my Raspberry 4, I find it powerful but at the same time having some problems, like for example that Atari or PSX games can be loaded from the core but not recognized when scanning the rom folders (they don’t appear under a PSX or Atari icon like the SNES games), and that I have no idea of how I can add the box scans. Can someone help?