Custom D.E.O.T. V1.0+/Clockwork OS v0.4 image - With Updated Kernel 5.3.6, Latest Lima Drivers, RA1.8.1, Mupen64+ and much more! (Current version: 191122)

Yup, that sounds like what @guu said, re installing the drivers in the user directory, and it being just a temporary means to test out the Lima drivers. An apt upgrade will end up breaking it.

Earlier, there was a post from @shell, mentioning how the driver works. That should hopefully shed some light on what was happening re: driver changing problems.

As for Retroarch slowing to a crawl, definitely sounds like it’s due to a lack of Lima drivers caused by the above problems. I’ve got the config set to the XMB interface that only really behaves with Lima. A solution temporarily is to change to the rgui menu driver.
Re: quake and gpsp not working well, is this just on a clean image, or after doing an apt upgrade and/or switching drivers?

Definitely worthy of knowing, bug testing wise re: things that will just not behave. I’m fairly sure these problems would occur, even if you applied the kernel/Lima driver update on a vanilla 0.4 image. While I’m here, also a reminder to not change to the other two launchers for now. I had problems with booting after doing this. It’s not an important feature for now, so I haven’t looked into it, but definitely will when I do the other tweaks.

Thank you so much for testing the image so thoroughly!!

why don’t you simply use my custom apt repository and provide .deb packages for mesa-lima and others ?

this would throw away all your apt-get update issues and remove all the self user compiling part

As for Retroarch slowing to a crawl, definitely sounds like it’s due to a lack of Lima drivers caused by the above problems. I’ve got the config set to the XMB interface that only really behaves with Lima. A solution temporarily is to change to the rgui menu driver.

The image I downloaded seems to use rgui by default. but even that becomes unusable. Anyway, I just got to wait til the lima driver is more stable before I can get Quake working. (I haven’t tried recompiling mesa and lima after using apt. maybe recompiling against the updated libraries fixes it?)

That would be possible, but is easier said than done. Someone would have to maintain the packages and recompile against newer libraries. Let’s just hope that lima keeps on making progress and the CPI kernel changes will be merged into linux-mainline. That would open up the device to a ton of customization as you could easily run other distributions on the device and update using the package manager that comes with the distribution without breaking things.


You took the words right out of my mouth.
With the current Lima updates installed in the user directory, I don’t believe it would an easy push. I’m intending on waiting for the devs to base a new 0.5 version or later using some of the recent finds.

@r043v If you’re keen to look into using your custom apt repository, that would be great. For now, it’s also a problem with doing an apt (I don’t use apt-get personally since it’s technically older than apt - but that’s just a personal choice and a topic for another day) updating the dynamic library, but not currently being compatible with the current driver configuration. It’s not technically a hard thing to do, but will also need to be done before using a custom repository.

If you can provide a link to your custom repository, that would be great.

@CommanderKitler I’ll try an apt upgrade, then recompiling things. Thing is, with buster as the stable release now, I’d have to really test the craziness out of it to make sure nothing else breaks. I released the image as it is now, since @guu tested his findings on my image; so I wanted to keep as many variables the same as possible.
Previously when I installed buster a few months back, before it got moved to the stable release, switching drivers broke, no doubt due to the dynamic library no longer being correct as mentioned above. There were also reports of Bluetooth and sound problems.
Maybe things are better now. Either way, I’ll upload a test image if you’d like, and for anyone else who wants to test things out. (And get rid of those Roms!!!)
As for the menu, ah yes you’re right!! I did set it to RGUI, fearing people may have compatibility/speed issues. I personally always use the XMB menu driver, since it makes accessing Roms within Retroarch easy, once you’ve populated your library etc, including cover art and info.

Before it gets too buried, here’s the post with the download links:

here was the forum thread about the custom repository > Gameshell ecosystem?

repo is at this time for stretch debian release

1 Like

There seems to be development going towards buster, and with it now moved to stable, I wouldn’t be surprised to see it become more mainstream in any upcoming official releases.


I’ll wait to see what happens before investing time and effort into something that may become obsolete. But by all means, if you can do it, I’d love to see your results.

Just as a side, which quake were you trying to get running? There seems to be an older thread with it working.

More to the point, did the recent driver changes/kernel inadvertently break quake 1 working? I haven’t actually tried it myself, so can’t really comment either way.

I basically did the same thing described in the thread. I had the .pak files in a different location for testing purposes, but that shouldn’t make a difference. It runs smooth with lima but it won’t render properly with artifacts on the screen making it unplayable. In software mode using fbdev it renders fine but it runs at a framerate comparable to retroarch (<1fps) so I guess the current version of lima breaks it.

1 Like

Oh I have to update that post, as the new version is released

1 Like

Whoops! I think I pasted the wrong link as the example of development moving towards buster! Haha I was definitely looking at integrating your work into a future release @Petrakis
All the better for keeping things up to date and current! :slight_smile:

On the other hand, re: quake being broken, if anyone wants to use a version of the image without the newer kernel and Lima drivers, have a look at first post of this thread, and download the 191111 version that @guu has uploaded. It will have the original 0.4 kernel and drivers, and will have a functional launches switcher, and anything else that may have broken since the kernel/driver update. In the grand scheme of things, I guess you could call the 191111 version stable and 191122 experimental? That said I use the 191122 as my daily driver with no real consequent adversities.

Ok so I got Quake running (kinda).
At first I tried to get eduke32 running so I cloned the git and ran make … missing libraries/includes. So I used apt to get the missing files (yup bad idea) and voila - it built successfully. I used scp to copy the game files and started it and it ran awfully. The same with retroarch. So getting the dev-files through apt broke lima. I backed up my user directory, flashed the image, scp’d the userdir and played some duke3D. I then realized the problem with quake was me using apt to download quakespasm. So then I got the quakespasm source code and tried to compile that but a lot of libraries where missing. To fix that I did the only “rational” thing - I downloaded the deb packages to my archlinux desktop, unpacked them and copied them onto the sd (overwriting most of the older libraries on the image)

that shouldn’t have worked but it did.

So i set up Quake aaaaand had the same horrible graphical glitches as before.
That was when I started to take a look at quakespasms manpage and saw that there was a couple of OpenGL extensions that could be disabled:

          Disable the use of the OpenGL multitexture extension.

          Disable the use of the OpenGL texture combining extension.

   -noadd Disable the use of the OpenGL additive texture environment

That got rid of the worst glitches.
It still has some problems:

  • 2D assets like sprites and particles are not rendering their alphalevel properly (transparency) so all 2D assets have pink squares around them
  • Shadows don’t render properly they have a kind of weird zebra-effect to them
  • Certain lights flicker very badly
  • there are some slight clipping issues with enemys flickering through walls at certain times.

Some of the same glitches can be seen in eduke32 when using the standard renderer instead of the classic one. So I guess the version of lima/mesa used in the image has some extensions broken that still work in the official 0.4 image. And it seems that it is not updated libraries that break lima it is just apt in general.

1 Like

Definitely sounds like an artefact of having the drivers installed in the user directory, then doing an apt upgrade.

Just to clarify; was the remedy more or less to do the above, without having done an apt upgrade? Another solution i might look into is doing an apt upgrade, and THEN doing the Lima driver upgrade AFTER. Theoretically, installing quake/duke should work.

The glitches that are present sound similar to those experienced in mupen64. That said, they’re still an improvement over what they were before, ie huge black boxes and chuggy performance. Given they’re the same problem, it might point us towards a solution. Thanks for posting up your findings!

For testing, could you share your unpacked deb files that you copied over, with your changes to extensions? I am extremely curious now!

Just to clarify; was the remedy more or less to do the above, without having done an apt upgrade? Another solution i might look into is doing an apt upgrade, and THEN doing the Lima driver upgrade AFTER. Theoretically, installing quake/duke should work.

Kind of the eduke32 version I build needed some includes from some **-dev packages but it seems to use statically linked libraries as it runs fine on the clean image I flashed after that. Maybe I can upload the version I compiled for the CPI, It should run out of the box. Quakespasm on the other hand uses dynamic linking for its libraries. It has a lot of build-dependencies and run-dependencies: libopusfile, libvorbisfile, libmad, libflac, libmikmod, SDL2, libgl, libc6(glibc 2.29), libgl (libgl-mesa-*) and more and each has their own deps.

I can upload the libs I unpacked but I strongly discourage from using them. I only added a new library every time quake would output a missing library error. There is a good chance that this setup runs into dependency issues when running certain applications (or I got lucky and satisfied all deps). This is a really dirty workaround for the apt issue, getting lima to survive an apt or dpkg update/install would be far better.

Disabling the GL extensions can be done with command line arguments I basically made a with the following content:


/path/to/quakespasm -current -noadd -nomtex -nocombine -basedir /path/to/id1/

I could also try to compile quakespasm again trying to force it to use static libraries. It would expand the executables size but should run without copying my libs.

Anyway It’s gonna take me a while to upload the files as I am away from home for work for the week and I have left my CPI at home.

1 Like

Theoretically doing an apt upgrade to get all the dependencies and extensions first and then doing the Lima upgrade process (again) should set things right. I’ll see what I can do if I have time. Let me know how you go too.

Mark didn’t help with that?

1 Like

Haven’t tried that yet. If mesa is the only thing causing trouble, it should work for a while. If so reinstalling the version of mesa using ninja install and mv to move the libraries after an should also work right?

so when I wanted to run an update I could just make a shellscript like this:


sudo apt update && sudo apt upgrade

sudo ninja -C /home/cpi/mesa/build/ install

cd libdrm-2.4.100
sudo make install

sudo mv /usr/lib/dri/ /usr/lib/dri/

sudo mv /usr/lib/dri/ /usr/lib/dri/

sudo mv /usr/lib/lima /usr/lib/lima.old/

sudo reboot

Would lima still work after that? If not I could “make clean”/ “make mrproper” then ./configure , make && make install (same with meson and ninja for mesa). Is there anything in the updates thats really breaking lima or is overwriting them again with the self-built mesa versions enough to restore functionality?

1 Like

One thing I can see breaking are the previously mentioned dynamic libraries used to trick the gameshell into changing between FBTurbo and Lima drivers.

It may be worth using an image that hasn’t had the Mesa/Lima built yet, and trying to install everything in a less volatile location, ie not the user directory. That said, I don’t know if people use any user other than cpi anyway.

I’m curious as to what exactly does change after doing an apt, making things break.

Unless people are actively developing or using newly developed tools that depend on the latest version, I should hope that the regular “user” shouldn’t do an apt upgrade without being fully aware of what they are doing. Old/fast is sometimes better. But nonetheless, I’m just going to put a disclaimer here. Don’t do it, unless you know what you’re doing. :slight_smile:

I do apt upgrade on boot almost all the times :stuck_out_tongue:

A crazy idea but maybe you could track with a version control like git and then do a git status to see what changed in the folders haha

Ha, you’re definitely the dev kinda person who would benefit from regular apt upgrades :wink:
Back when I used to have a Linux machine as my day to day computer, I’d probably reboot it… maybe once a month? And that’s usually due to someone tripping the power or literally tripping over a power cord.

I have thought of having a version tracker/git submission but ultimately, I … was too lazy to do it. But if there’s enough demand for it, I’ll do it. Or if anyone else wants to, I sure won’t say no!

Here is another download link deot_v1+ 191122.img.tar .bz2,hope it’s helpful to someone who’s in China.

1 Like