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)

Thanks! That’s a huge compliment! Essentially, it is still the same as the stock 0.5 image, just with periodically maintained additions, and the assumption that I know people who have my image have things set just the way I know I put them on mine. In reality, it’s a way to make helping people slightly easier.

I’ll have to run a poll to see if anyone else would want zdoom. The last thing I want to do is include too much bloatware. If it’s just as easy to provide an installation script for optional items, I’ll just write them out instead.

Re: the XMB interface being too small, give this a go:

  1. Open retroarch, with the XMB interface enabled
  2. Go to the settings page, and select User Interface
  3. Scroll down and select Appearance
  4. Adjust the Menu Scale Factor left and right.

I found that 1.00 scale was a good enough readable resolution, while still being able to see the general menu layout.

1 Like

Yes, good idea those scripts for optional items like zdoom if it doesnt get votes.

Thanks, the scale I got is the same you say, just me being a bit picky hehe.

Also, just for imformation for others, I think it’s problem of the base image 0.5.
I tried Blood and Shadow Warrior and works on the FBTURBO driver. Not on LIMA.
But Duke Nukem 3D works on LIMA.

1 Like

Thanks for testing that! I hadn’t actually tried either of them, since 0.5 hit! Good to know!
Just to add to the list, the same thing can be said about Quake 1 (quakespasm). The menu alone loads up all glitchy. It runs, just with a lot of graphical glitches. You’ll need to use the variable -nomtex to get it running on Lima.
Runs like a train stuck in a blender using Lima.
Runs like a train with spaghetti stuck in its wheels using FBTurbo.
Basically, either way, it doesn’t really run desirably well.
Strangely enough, Quake II (Yamagi)works AMAZINGLY well using the Lima drivers. Like. Buttery and smooth.
I was hoping to do away with having to use the FBTurbo drivers, but looks like we still have a use.

1 Like

The next thing I’m undertaking is re-ordering the .config/retroarch directory to be WAY more streamlined, and correct.
Currently in the config, there are a lot of defined directories. I don’t think anyone has actually come to some logistical consensus of what and where everything should be, considering most of them haven’t been defined by default. I’m hoping to change that, at least using the structure I have in place as a base.

This is what it currently looks like
core_updater_buildbot_assets_url = ""
core_updater_buildbot_cores_url = ""

system_directory = "~/apps/emulators/bios"
libretro_directory = "~/.config/retroarch/cores"
libretro_info_path = "~/.config/retroarch/cores"

assets_directory = "~/.config/retroarch/assets"
core_assets_directory = "~/.config/retroarch/assets"
cheat_database_path = "~/.config/retroarch/cheats"

runtime_log_directory = "~/.config/retroarch/logs"
log_dir = "~/.config/retroarch/logs"

content_database_path = "~/.config/retroarch/database/rdb"
joypad_autoconfig_dir = "~/.config/retroarch/autoconfig"

rgui_browser_directory = "~/.config/retroarch"
rgui_config_directory = "~/.config/retroarch/config"

audio_filter_dir = "~/.config/retroarch/libretro-common/audio/dsp_filters"
video_filter = "~/.config/retroarch/gfx/video_filters/Scanline2x.filt"
video_filter_dir = "~/.config/retroarch/gfx/video_filters"
video_shader_dir = "~/.config/retroarch/shaders/shaders_glsl"
video_layout_directory = "~/.config/retroarch/layouts"
overlay_directory = "~/.config/retroarch/overlay"

playlist_directory = "~/.config/retroarch/playlists"playlist_entry_remove_enable = "1"
content_favorites_path = "~/.config/retroarch/"
content_history_path = "~/.config/retroarch/"
content_image_history_path = "~/.config/retroarch/"
content_music_history_path = "~/.config/retroarch/"
content_video_history_path = "~/.config/retroarch/"

screenshot_directory = "~/.config/retroarch/screenshots"
thumbnails_directory = "~/.config/retroarch/thumbnails"
recording_config_directory = "~/.config/retroarch/records_config"
recording_output_directory = "~/.config/retroarch/records"
menu_wallpaper = "~/skins/DEOT/"

input_remapping_directory = "~/.config/retroarch/config/remaps"

savefile_directory = "default"
cursor_directory = ""
dynamic_wallpapers_directory = ""
cache_directory = ""
resampler_directory = ""
bundle_assets_dst_path = ""
bundle_assets_dst_path_subdir = ""
bundle_assets_src_path = ""
content_history_dir = ""
core_options_path = ""

Here’s the entire config
I’ve just reshuffled like config items together to make it easier to think.

There are a lot of gaps that can be defined. Furthermore, the stock image has a lot of extra directories and files residing in .config/retroarch that unless they’re referenced in the config, probably can be removed. I’ll have to see what else ie loaded when running retroarch from /usr/local/bin, but I’m fairly confident that it shouldn’t be too much.

If at least we have all the directories defined along with key bindings, we should be able to make a script to amend a stock retroarch config, making it a far less menial process, when we need to update retroarch. I’ve had far too many bad experiences with using an old config in a newer build to dare risk just copy pasting my existing one.

Speaking of, I’ll probably write up small scripts to update the existing DEOT OS v2 to whatever the current version is, as well as provide a pre made image, just for the current and last image. That way, having to wipe your image every time shouldn’t have to happen. Fingers crossed.


@javelinface check this about twm

1 Like

Oh snap! Thanks for the heads up @Petrakis!
Applying this on the stock image might end up being a case of another update, ala the 0.4-0.5 route. There may be a few people who could have difficulty with this. I’ll definitely apply this to the custom image myself; or if there’s a 0.51 image, wait for that as well. It shouldn’t be too hard actually, since it’s all just within the launcher. Writing a script would be super easy. I might do it soon.
Either way, it’s happening :slight_smile:

Here’s a small script to do the change.

wget -O /home/cpi/
chmod +x /home/cpi/
Contents of the script:

echo "----------DELETE LINE 10----------"
sed -i "10d" /home/cpi/launcher/.xinitrc
echo "----------WRITE LINE 10----------"
sed -i "9 a \	exec /usr/bin/twm -f ~/launcher/.twmrc" /home/cpi/launcher/.xinitrc

echo "----------DELETE LINE 11----------"
sed -i "11d" /home/cpi/launcher/.xinitrc
echo "----------WRITE LINE 11----------"
sed -i "10 a \	#exec ~/launcher/dwm-mod" /home/cpi/launcher/.xinitrc

echo "----------DELETE LINE 19----------"
sed -i "19d" /home/cpi/launcher/.xinitrc
echo "----------WRITE LINE 19----------"
sed -i "18 a \	exec awesome -c ~/launcher/awesome/rc.lua" /home/cpi/launcher/.xinitrc

echo "----------DELETE LINE 20----------"
sed -i "20d" /home/cpi/launcher/.xinitrc
echo "----------WRITE LINE 20----------"
sed -i "19 a \	#exec ~/launcher/dwm-mod -w" /home/cpi/launcher/.xinitrc

echo "----------CLEANUP----------"
rm /home/cpi/
What I did

For those of you wanting to do what I’m about to do to their own image, I’ve modified /home/cpi/launcher/.xinitrc from"


case $session in
hdmi )
	exec ~/launcher/aria2c --conf-path=/home/cpi/launcher/aria2.conf &
	feh --bg-center ~/launcher/
        cd ~/launcher/ ; python > /tmp/appinstaller.log & cd ~/
	exec ~/launcher/ &
	exec ~/launcher/ daemon &
	#exec /usr/bin/twm -f ~/launcher/.twmrc
	exec ~/launcher/dwm-mod
gameshell )
	exec ~/launcher/aria2c --conf-path=/home/cpi/launcher/aria2.conf & 
	feh --bg-center ~/launcher/
        cd ~/launcher/ ; python > /tmp/appinstaller.log  & cd ~/
	exec ~/launcher/ &
	exec ~/launcher/ &
	#exec awesome -c ~/launcher/awesome/rc.lua
	exec ~/launcher/dwm-mod -w
	exec $1;;



case $session in
hdmi )
	exec ~/launcher/aria2c --conf-path=/home/cpi/launcher/aria2.conf &
	feh --bg-center ~/launcher/
        cd ~/launcher/ ; python > /tmp/appinstaller.log & cd ~/
	exec ~/launcher/ &
	exec ~/launcher/ daemon &
	exec /usr/bin/twm -f ~/launcher/.twmrc
	#exec ~/launcher/dwm-mod
gameshell )
	exec ~/launcher/aria2c --conf-path=/home/cpi/launcher/aria2.conf & 
	feh --bg-center ~/launcher/
        cd ~/launcher/ ; python > /tmp/appinstaller.log  & cd ~/
	exec ~/launcher/ &
	exec ~/launcher/ &
	exec awesome -c ~/launcher/awesome/rc.lua
	#exec ~/launcher/dwm-mod -w
	exec $1;;

Basically commenting out the DWM and enabling the TWM.

The changes are to do with how the window managers behave, in particular when plugging in via HDMI. You probably won’t notice anything if you only use your gameshell handheld.

It does however seem to make the launcher icons move a bit smoother, but also a bit slower. I’ll have to do a side by side comparison to check.

You will also need to edit the ~/.config/retroarch/retroarch.cfg file, and have fullscreen enabled. Windows mode doesn’t scale well, and will be zoomed in like crazy after enabling twm.
Look for this line, changing it to true:

video_fullscreen = "true"

I’ll add this to the script tomorrow too.

I’m torn whether to include this. It sounds like it’s going to be implemented in a future official release anyway, but I’m not sure if people are more used to the DWM menu movement now.

Try the script above out if you have some time. It works for both the DEOT version and the official 0.5 version. I’ll make a second script to revert it back if anyone wants it.

Let me know if in the next release I should:

  • Change to the TWM window manager
  • Keep the DWM window manager

0 voters

Also from the previous poll, it looks like most people don’t want any extra pre installed standalone emulators, but had some interest in the Emulationstation front end. This will most likely be mainly associated with Retroarch.

1 Like

all the 3rd party softwares could also be setup at user choice, so be external by using an apt or warehouse repository

what are the differences between the two window manager implementation ?
are they really usefull as clockwork os doesn’t allow multitask ?

3rd option is to use my customized monsterwm,
it will give you anywhere sound/backlight control, allow context switch between windows and could ask any window to close

1 Like

I have thought about having every single option buildable via the warehouse, from a stock 0.5 image.

I’ve only applied this one, since it’s going to be something according to the GitHub entry that will be implemented later on in the official image. Just so there’s less things to update later on. I honestly can’t say what’s different between them, besides how things are animated.

Re: multi tasking via monsterwm, If people are wanting to have it, I’d put it in. I’m interested in using it in my own day to day OS. For now, I’m hoping to have as close to what a spiritual DEOT OS would be, if one were made today; while keeping things that are fairly stock updates.

Just for comparison, here are the two stock window managers side by side. Left one is DWM and right one is TWM.

You can see how they are comparatively. TWM is smooth, whereas DWM is snappy.
I do recall that DWM is painfully slow via HDMI. I’ll try it out later, comparing the two. Hopefully TWM is faster.
Potentially, I could even have one window manager for handheld and one for HDMI.
The next question is: who actually uses HDMI with the Gameshell often? I only use it when playing PokeMMO personally.

Just reposting this poll in case it was missed:


it doesn’t make sense, the wm just place window on the screen, arrange their size and read events

dwm is pretty minimalist, like monsterwm
twm else is more for a desktop use, can showing title bar & co

so dwm must be the fastest, but any of them must be invisible in performance

100% Agreed. It would be next to negligible given the resolution, and the inability to really have multiple windows.

The main thing that gets affected are things like Retroarch that can specify to be run in a window mode, vs full screen. That presented a problem using TWM, even specifying a windows size. I had to revert to fullscreen.

The only reason I can see for running TWM as the default over DWM is for HDMI use, and to have less redundant apps, if having both. As mentioned above, DWM performs terribly over HDMI for some reason.

One thing I have noticed since switching to TWM is Retroarch having a visible mouse cursor now; even in handheld mode. Useful, especially if using the mouse mod flashed to the arduino.

This is mainly a reflection of what is covered here:
If this indeed is going to be what is standardised in the future, tackling it early, and giving feedback can be a good way to test it before implementing it; using the modified DEOT OS.

1 Like

@javelinface I am experiencing a booting loop with the latest version on startup that eventually results in a blank white screen.
My gameshell resets at the clockwork logo continuously. I tried plugging it into power.

I thought this might be the partition expanding onto the 32gb card but I have now bricked two SD’s (oops)
I have tried reformatting them with command prompt and a Mac computer but no luck. They remain corrupted and/or inaccessible.

I don’t think this is your image I think the download or flashing process might have had issues.
I will try updating etcher tomorrow and downloading the image again before flashing it.

I am using the Kickstarter edition of the GS if this would cause issues

Interesting. The Kickstarter one may have been a generation 1 CPI.
Can you confirm whether or not it has an HDMI output on it?
One thing you could possibly try is changing the kernel of the image.
I’ve got a link to a compressed archive with two folders; one with the stock kernel (0.5) and one of the older stock DEOT kernel (0.4)
The older kernel was before change were made to make the GPU Drivers work. See if this helps.
You’ll need to plug your SD card into your computer, mount the Boot partition (it should by default) and then replace the contents with what is in the DEOT kernel folder.

Is this a problem you’ve got with the stock 0.5 image too? And when you say bricked SD card, can you not write to it anymore? I’ve had some cards entering a state where you cannot write to it, no format it; entering a protected mode. This happens especially with my old GO PRO 3+ when it runs out of power, and abruptly interrupts the writing of data. Something similar could have happened here.

FWIW, with my Sandisk cards, I’ve contacted their RMA dept. they are aware of this happening and generally ship out a replacement card for free, no questions asked, after you send in your faulty one. No receipts were needed even. Who keeps receipts for SD cards?

This leads to another thing that could be happening if you have a kickstarter edition is your battery could be on its way out. I know my older gameshell sometimes has trouble starting up, unless it has the power plugged in. It will sometimes just turn off as well, even though it reports 40% power is left. Batteries are just a consumable part of electronics these days, just like phones and laptop batteries.

Yes it is generation 1 CPI, there’s no HDMI just a micro USB.

I try a stock 0.5 image tomorrow. If that works I’ll replace it with yours and try again.

Exactly like you say the SD’s are unreadable and refuse to be read or written to despite me trying several command processes and workarounds.
It seems the gameshell is repowering continuously because windows made beeps every ten seconds when it turned back on.

The system works fine with my original OS on the SD that came with the unit. Battery life is about five hours emulating SNES.

It sounds very much like a write protect fallback, after an erratic power problem. Might be worth starting a new thread over it, regarding how to recover from it. What I can offer for now I this:

But the more pressing and important issue at hand is the fact that there may be other users out there with a kickstarter first gen CPI. I just assumed most people would have upgraded to the new board when they offered free postage etc. I’ve never owned a first gen cpi to test on so honestly can’t say either way how things would run.

When you say your original OS that came with the unit, that would have been … gosh, 0.2??? Or 0.1 even? You’ve been here since the beginning I take it? If you ever upgrade to the 3.1 board, you’ll be in for a world of difference!

Perhaps for now, try a 0.3 or 0.4 image. I have a feelin the kernel is behaving. 0.5 comes with 5.3.6 stock, but also has 5.4.6 tucked away ready to be renamed and used. It isn’t used by default, due to some compatibility problems with different batches of soc.

I have the Kickstarter board (no hdmi and half the ram) and the stock 0.5 runs fine.

1 Like

Phew! You saved me having to write a disclaimer!
I guess that rules out having to use an older kernel for the older board.

It could just be an old card, which has been written too many times, with bad sectors over the threshold amount.

If it’s using the current DEOT 200128 build, that one doesn’t do the automatic resizing, re: any concerns about partition etc. Besides that, it is basically a stock 0.5 image, just with a few things updated and fixed up. None of them should affect any of the core functionality or startup of the image relative to stock.

You’re right it’s an error somewhere on my end.

The second SD I tried it on was brand new.

I will try the stock 0.5 OS on a new SD and redownload your image in case something went wrong there.

In the meantime I’ll probably purchase the new CPI also.

1 Like

@javelinface do you recommend the full DEOT Gameshell for this project?

I could upgrade my CPI but I note the DEOT has a better battery.

And a pretty badass appearance.

1 Like