Custom D.E.O.T. V2.0+/Clockwork OS v0.5 image - With customised DEOT interface, Kernel 5.7, Optional 1400MHz OC, Debian 10 Buster, Retroarch 1.9.0, Mupen64+ plus more! (Current build: 200903)

My two cents would be at the black theme :joy:

Battery savings from using a dark theme with OLED screens are drastic: Google saw battery life savings between 15% and 60% when it moved from YouTube’s default white background to the dark mode.

1 Like

Agreed! The contrast is better too, so for just menu use, you can dim down the screen; plus it’s easier on the eyes!

Ok so I redownloaded the image last night and updated Balena etcher to the latest version.
The problem was still there, so I reflashed with the stock 0.5 OS.

Same issue. The gameshell perpetually restarts when turned on.

It still works fine with the original OS.

What can you do…? I will just have to save up and wait for the newer units to go on sale. :grin:

I have had this exact problem before, and basically did what I mentioned re unplugging for long periods.

Check out this thread. Sounds like a similar problem to yours.

A thought.
It only really charges when the logic board tells it to. Use the old image that works to fully charge your battery perhaps.

It’s strange that it’s only the new image that is affecting things.
Just try this for now. Replace the contents of the boot partition with the files in the here. That’s the only thing I can think about.

Hi Javelinface,

I just flashed the deot_v2+ 200128 img and noticed that RetroArch is not in a good shape. UI elements are overlapping/overlaying each other when moving in the menu, sometimes hangs the device.

I was wondering if you can tell if you have time and plan to roll out a new release soon with the fixes mentioned above?

Thanks in advance

This is just the XMB menu. It was excluded in the stock release, possibly for this very reason. I included it for people who use the Gameshell in HDMI mode; something I do a lot. It becomes a lot more readable on a big screen. Although did you mention overlapping menu components? That sounds like the assets haven’t been downloaded for some reason. You can redownload the assets in the online updater page in Retroarch. It also shouldn’t be hanging the device. Are you using the Lima graphics mode?
You can change it to the regular rgui mode by going into the drivers setting page in Retroarch, and changing the menu driver to rgui. That should be less taxing on the Gameshell, but less of a standalone GUI for loading and arranging Roms. I made a screen shot in this post
I have an image that is ready to go, but haven’t uploaded it yet, since it only has minor hot fixes here and there. I’ve provided instructions on how to apply the fixes in the most recent posts above. This is due to a lot of people not wanting to have to wipe their images just to apply a small change. Are these the fixes you are referring to? Or just the ones from your own post?
I’ll upload it today, and have the release notes written up shortly after.

DEOT v2+ Build 200224
24th of February 2020

Current changes:

  1. xbindkeys installed to allow key shortcuts to exit/kill apps that don’t have easy termination processes. eg, sampler box and scummvm.
  2. Samplerbox shortcut in utilities. (Exit it using menu key) thanks @edward
  3. Scummvm shortcut made in Retro Games. (Exit using shift+A+B+X+Y) You will still need to sudo apt-get install scummvm. I have omitted from doing this on this release, as you will not be able to use this unless you’ve installed the mouse mod to the arduino. Unfortunately, I can’t do this from the image end.
  4. Slightly modified .xinitrc that uses twmrc in HDMI mode, but sticks with dwm-mod in handheld mode. There were no benefits in hand held mode, and it only made the interface slower. We’ll see how the mainline image tackles it in the future, and go with whatever is chosen then. I personally don’t have this on my day to day image, but I know that people will complain about the slower menu speeds.
  5. Cleaned up and optimised mupen configuration, and action.config to reflect using a /usr/local/bin file location.
  6. Quake 2 shortcut removed.
  7. Returned freedoom part 1 and 2 - I previously deleted, while culling all games.
  8. DEOT Skin settings items modified to have the appearance of stock, with the colour of the DEOT interface. I still can’t get the modified items to work. I believe it’s a font issue or something else referenced in the file.
  9. The OP-1 theme has been returned, and adequately doctored to reflect the new file structure of 0.5. Likewise, Canisminor has been included with similar fixes.
  10. Fixed the vertical justification of the /etc/motd file so that the welcome splash message better reflects the stock DEOT OS.

Previously mentioned updates reiterated, with links to initial post:

  1. Tweaked retroarch config to try and have more of a focus on vsync and screen tearing issues, than audio timing/skewing. It seems that most people care about visuals more, than actual frames and audio quality. On my day to day image, I personally prefer to have Vsync off, and just have audio sync, since it gives more reliable frame rates, and better audio. But screen tearing is what people see, so lets see how this goes. see here
  2. Font overlap fixed
  3. DEOT Apps cleaned up
  4. Cleaned up some of the retroarch directory structure
  5. The initial tweak to the .xinitrc reference to the window manager

Things I haven’t done:

  1. Installed Emulationstation. It’s just not reliable/stable enough yet.
  2. Installed Brutal doom. Not everyone will want this.

It is being compressed and uploaded as we speak. For now, it’s on google drive, just so I can set it and forget it while I go to work. I’ll provide a mega link later.
It might also just fail uploading, because I live in Australia, and we have terrible internet.
The link will be the same one in the original post


It may be worth considering changing to Ozone for the interface as it appears that will now be the default in Retroarch. I haven’t tried it on Gameshell, but if the main development effort is there, it might be a good default to use if it’s stable/working on Gameshell.

Also, sorry I kind of disappeared. Haven’t had the time to completely move my stuff over from the old broken card, and set up the dev environment stuff again. I need to just take a whole day and do that :frowning:

1 Like

Oh haha, I also disappeared! My last update was a month ago! Life is… it is hard! :smiley:
I actually did initially use the Ozone interface, but that was WAAAY back before Lima was working, and well, basically, you couldn’t tell what was highlighted with the half done drivers.
The good news is, Ozone menu UI capabilities are also installed with this retroarch build, so you CAN in fact change to it. I’ll just need to tweak it a bunch to make it fit the 320x240 screen. As it is now, it barely fits!
I just mentioned rgui above, since the user was mentioning lagging menu problems and freezing. Rgui is about as bare bones as it comes - and looks absolutely horrible!
I fully agree with the move to Ozone.

Well this is annoying. Even changing to menu_scale_factor = "0.200000" doesn’t appear to make ozone’s scaling change. This is meant to be the official way to change the dpi scaling. Although, this is probably assuming more that people want to scale it to fit their larger 4k displays; not the opposite.

I’m going to investigate more to see what can be done.

The only ozone specific parameters are:

ozone_collapse_sidebar = "false"
ozone_menu_color_theme = "1"
ozone_scroll_content_metadata = "false"
ozone_truncate_playlist_name = "true"

Not much to work with. @adcockm See if you have any better luck.

1 Like


I have just finished picking up the pieces you mentioned and remediated my problem by them and just noticed you are more awesome than I already though and published a new release! Many thanks! :smile:

1 Like

Haha aww thanks!! I thought there wasn’t much to warrant an upload, until I added them all up and realised, dang; there is actually quite a lot!

Hopefully the links allow you to cumulatively add the majority of the changes.

Did you end up getting Retroarch working better? I’m curious as to what your overlapping problem was.

Really looking forward trying this out. Thanks!

1 Like

I was having the glitch in XMB when used the “Core Updater” option, it remain stuck and got overlayed with the other options when moving in the menu. I have switched back to RGUI, as it suits me better in overall, I’m not using the device on HDMI, just for handheld. Anyway, I will still stick with RGUI as it’s much easier to read on this small screen.

Today I have installed the new deot_v2+ 200224.img on another mSD, and noticed the problem on XMB with “Core Updater” no longer appear (although pressed Core updater once all of the other items were updated).

Excellent work on this new image!


1 Like


Noticed some minor glitches, can you please include a fix for them in the next release?
When using DEOT skin it seems the font is too big at the Airplane setting.
BatMon makes RetroArch hang - not sure how to resolve this.


1 Like

I won’t be able to fix the Batmon, but @Petrakis wrote it, so may be able to help!

As for the air plane mode, and the larger font, I’m trying to get the “proper” setting menu working. The current one is just a place holder. If you’ve ever tried the stock 0.4 DEOT image, you’ll know what it is supposed to be.

For now it’s a small enough problem, seeing as we shouldn’t be needing to turn airplane on and off too much.

Agreed, not a big issue, just wanted to let you know.
Thanks for the contact about BatMon, wrote him a PM about this.


1 Like

With the stock 0.5 or the custom one? I don’t think i’ve had this issue with the stock one, I will see if I can reproduce it.

I have experienced the issue with the DEOT_v2+ 200224.img which is based on the 0.5 stock one with RetroArch 1.8.4 playing Super Mario Land Rev 1 (GB) .
So it should work properly with the stock 0.5? I’ll make further tests.

It works for me, but it might be a very specific scenario where it happens. But I have my theory, its not that it freezes (You should be able to still do ssh), what I think it could be happening is that when BatMon is raised on the screen it steals focus from retroarch, so keypresses are directed to BatMon instead of RetroArch.

1 Like

It could be, thanks.

Regardless of all the efforts the community puts into the various side of deployments, and thanks BTW for all of you guys, we are still a long way from being ClockworkOS stable. I had tons of freezes like when exiting any game from RetroArch, or when loading games which worked before (with every official release) - Mostly using the RetroArch side. I guess it’s not a coincidence we still have version starting with zero dot x. I don’t want to demotivate anyone, but I think it’s a shame that during these years official gamesh development is still going so slow providing such a rocky experience on the user side.

Try using the older FBTurbo graphics driver. That should solve your stability problems. Of course that comes at the hit of less performance, but honestly if you’re using retroarch, besides the XMB interface, you’re not missing out on that much using the older graphics drivers.
The Lima drivers are still labelled as experimental. It’s there so you can test it out.

If you can provide examples of games that worked before that no longer did, that would be great so we can test it out and replicate the problems to find solutions. Include which drivers you were using etc.

The whole point of me making this image was to help solve problems for people with an environment I know is configured a certain way, and to apply universal fixes to help people have an image that does what you want it to. I’m desperately trying to advance us towards something that can be considered a stable OS.

Possibly consider trying this.
I never considered it before, but the window manager could be the problem regarding the reported crashes. I have personally changed to the twm manager, ie performing the above change, and haven’t had any crashes. The image I just released has a slightly modified hybrid that uses the dwm manager in handheld and twm in hdmi, simply because I assumed people would complain about menu speed problems. The vote I ran earlier had a 75:25 split, hence why I made a compromise.

I guess it’s a matter of the chicken and the egg. Things will go faster if communication gets better. Most people doing things are doing it in their own free time, out of the love for the console. As soon as it feels like a thankless job, with people cracking the whip at your heels, of course people are going to drop off.

On a lighter note:

AH! I just re-read this and realised what the problem you were facing was!
I made a typo in the buildbot URL, having instead of
One letter v. I made a typo!