Some time ago, I asked about desktop environments that could be controlled with a game controller - https://programming.dev/post/54830683

I decided to start with DietPi, seeing as it’s a much more minimal image than the minimal Armbian. RKDevTools burned it to the nvme just fine[1]. DietPi works fine, retroarch runs fine. Great.

Next, I install Kodi. For some reason, it doesn’t show me the screen: the terminal stays on screen, showing the entire log output, pressing keyboard keys make sounds of selecting options, but the graphical part of Kodi is nowhere. 2 restarts later, attempting with root and the normal user, same problem. A cursory search on the internet gave me nothing (dietpi kodi terminal). Fuck me.

I then install KDE. Similar to Kodi, it simply doesn’t launch. As I installed via the metapackage, I expected it would’ve installed with either lightdm or sddm (the login screen manager). In either case, running the command to start kde from the terminal simply gave me an error. Like with Kodi, I couldn’t find this or a similar problem on a search (dietpi kde won’t start) and it wouldn’t run either as root or normal user.

Oh, DietPi also took forever to finish booting up because it would take its sweet time checking eth0, then wlan0 (10s on each), then nearly a minute with journalctl.

Fuck that shit.

Armbian with KDE was the next option. Sure, I wanted to avoid a bloated desktop environment, but if it worked out of the box, I could just remove packages later. Lo and behold, it did! Setting up the controller to work was easy, too, yes! But boy, what a load of cruft! Luckily, Armbian offers, under armbian-config command, an option to downsize the full KDE to a minimal install. So I did.

By the way, did you know that Armbian uses a different network stack if you don’t use the minimal install? And that the package is apparently removed from the full KDE install if you downsize it? I didn’t until it happened. Guess how happy i was in finding out that Armbian removed THE ONE FUCKING PACKAGE THAT ALLOWED ME TO DOWNLOAD ANY OTHER FUCKING PACKAGE. Of course I didn’t immediately figure out what happened, it took some searching because the apt update error insisted it couldn’t reach ports.ubuntu.com despite me being connected to my wifi, despite the config file still existing, despite a couple of restarts. Only after I found the bit of Armbian explaining this idea of using a different network stack in a different flavor was when I checked and voilá, I had no program to actually turn on and connect to a network. You would think that there would at least be some warning somewhere, or that the default systemd.network package would be installed anyway but stay disabled in this default, but nope, just get rekt noob, fuck you.

Already feeling like going back to oPi’s own android rom, I trudged on and went with Armbian minimal. If that one failed or fucked itself over for no reason, I would give up. It does use a bit more memory and runs more processes than dietPi, but it doesn’t fuck around during boot, it’s fast, which is a huge plus. Before installing KDE minimal, I try to make a snapshot using timeshift. For whatever reason, it doesn’t work. It simply gets stuck with RSYNC doing fuck-all. Under normal circumstances, it should show the progress percentage. In my case, it would show 0.0%, then the line would disappear after a couple of seconds. Leaving it there for 20 minutes resulted in nothing, despite the total used space at the time being under 3GB. There goes my plan for avoiding rkdevtools yet again. Sigh.

I fire up armbian-config and install minimal KDE. It works! I reboot just to be sure it wasn’t a fluke and yes, it still works! Time to configure some stuff and… Where’s the settings program? Why is there no settings? Nothing to configure keyboard, power management, locale… What the fuck? Turns out that a minimal install of KDE does not install systemsettings, which is KDE’s package for configuring lots of stuff. I guess my notion of “minimal should include THE FUCKING SETTINGS” is wrong, but I digress. Once I figured the package and installed it, everything was fine. For 5 minutes.

To my dismay, plasma-bigscreen isn’t a package available in the repo and the fucking page only offers a x86_64 package for download. So that option was out.

I start installing some packages, like retroarch again, also Firefox. I launch the good ol’ browser and the screen immediately goes black, then shows the boot sequence. Huh. My first thought is that the board was overheating, as I forgot to properly connect the heatsink. All set, Firefox opens for 3 seconds then I’m rebooted again. Fuck me. I turn off the board, wait a bit, turn on, try again and FF crashes again. It’s not temperature and I have no fucking clue what could be instead. The solution was installing flatpak bazaar and then using brave browser (ugh, I know). It crashed once, but after I had like 10 tabs open. I also tried Librewolf but it crashed the system after i typed one thing to search.

Now, since I want to use this without needing a keyboard, I set up the controller again - the first time also happens to freeze the settings window for unknown reasons. Anyway, I successfully set up SDDM to auto login (after installing its setting package, because why would a minimal install need settings, right?), then do a CTRL ALT F4 to try retroarch in a different terminal. It runs fine, but when I quit, it immediately starts again. I quit again, then I see a bunch of repeated apt commands being tried again. I reboot.

You know the meme that getting audio running on Linux is a fucking mess worse than X11? There is truth to that. For reasons known only to bug gremlins, my audio stopped working[2]. Reboot, still no sound. Thanks to the memes, I at least know which packages to look for: pipewire, alsa and pulseaudio. Armbian installed pulseaudio, but not some of its settings. I go ahead and install some more packages, reboot again and finally get it working again, though the sound test window still complains that it couldn’t find an audio driver.

Now, let’s see if retroarch actually works. Hm, I’m sure it was supposed to have an option to download cores. As a matter of fact, it does, but it’s hidden by default in the linux install, so I go to /home/fist/.config/retroarch and manually edit retroarch.cfg so it’ll show the option to download cores. Only it doesn’t work and also breaks the UI. The log complain it can’t write to the folder, though the UI breaking isn’t logged, it’s just a neat side effect. After some fucking around and manual downloads - which also refuse to be installed due to write permissions - I set a folder in /home/fist/libretro as the one for retroarch to look for the cores and throw all the cores there, including copies of the ones installed via apt.

It’s finally working, though I’ve yet to stress test Dolphin (flatpak version) or Flycast, which should be the more demanding emulators. One of the reasons for the change was that the orange android’s version of dolphin was insufferable with detecting controls and would often crash after a while. If that repeats here, well, I’ll feel it was all for nothing.

I’m not too keen on KDE taking ~1.8GB of RAM either, so I might experiment with alternatives, like getting Kodi or Flex (which I’ll have to use the rpi package) to run instead of it, although trying to logout immediately logs back in with KDE again - due to my SDDM config.

So, the tally of problems I encountered:

  1. No plasma-bigscreen for aarch64
  2. kodi wouldn’t start its graphics (dietpi)
  3. kde wouldn’t start (dietpi)
  4. slow boot (dietpi)
  5. armbian removing the network control package without a fallback
  6. timeshift wouldn’t work (armbian)
  7. minimal KDE doesn’t install system settings (armbian)
  8. couldn’t connect 2 bluetooth controllers at the same time (armbian)
  9. Firefox/Librewolf consistently crash the system (armbian)
  10. KDE activating the lock screen despite no option toggled to do so (armbian)
  11. audio stopped working (armbian)
  12. Retroarch refusing to download cores; failing to install cores from a directory (armbian)

I understand the concept of rough edges and that, for ARM in general, it should be expected from linux distros, but some of the problems I faced are less rough edges and more stupid fucking design - I mean this especially on problems 5 and 7

  1. I absolutely hate that the program uses a 2-step disconnect/connect to the usb, which led to many a failed attempt to burn the image. What I mean is: first it writes the uboot image, then it enters a “Waiting for loader” state where it has to send a signal to the board and/or wait for it to boot under LOADER mode. For whatever reason, I had a very high failure rate in this step, whether due to cable or usb port, I’m not sure, but it was a fucking headache. I really wish you could do it step by step in order to avoid this kind of problem ↩︎

  2. It’s possible the reason was one of the apt commands that ran during my retroarch test above, which begs the question of why the fuck the terminal went crazy and tried to run those commands right after quitting the program I ran and without my fucking input ↩︎