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.8.9, Mupen64+ plus more! (Current build: 200626)

Ok I did what you said, but still nothing, same error…and i’m in the folder…so, can’t do step 4 with the CMAKE…Also I saw what Javelinface said, that it’s possible to don’t do those steps, but I don’t get what is suppose to be the next step in his answer :S

The issue you have is with the step 3… On which GS OS are you? 0.3, 0.4, 0.5 ?
Try another method just to see if it help, you will still have to do the other steps though.
Erase everything again.

git clone

cd zdoom

cmake . -DNO_OPENAL=ON

make -j4

1 Like

Ok great, now it’s working, thanks!

I have to write down all the steps hehe

1 Like

I might include a fully configured zdoom in my next release. ;).
The tutorial from @lix is missing the install step, and leaves the build files and sources behind, so is a bit messy. I’m a bit OCD when it comes to leaving “dirty dishes” in my launcher. (And in real life!)

@lix that step you mentioned above:

cmake .   **-DNO_OPENAL=ON**

It disables openal. Are you sure you want that? Also I think it needs a double dot.
There’s a typo in your code re:

You have three dots (…)
It’s meant to have two dots (..)

I’ve made a rough script to automate it all for you. It installs to the launcher’s home screen, so move it to wherever you want afterwards.

wget -O /home/cpi/
chmod +x /home/cpi/

Anyway probably better to take all this discussion to the right thread. This is getting a bit off topic.

Back on topic. The things in Japanese (it’s actually Chinese) are the DEOT exclusive extra apps/games. I call them the edge lord apps. They’re purely decorational, and exist to make it feel like you have some kind of 1337 underground hacking unit. Nonetheless they’re things featured in the stock DEOT OS, and things that make that OS special.
You can honestly ignore them if you want, and even delete them. Since they take up so much space visually, I am going to put them in their own folder in future. I provided instructions above on his to do this.

1 Like

This script is specifically for my DEOT v2 200128 build, and uses the directory structure for the launcher items, ie, Retro Games>id>zdoom. It has the DEOT style icon to match.
It’s the same as what I’d be including in a future update, basically; if I decide that it’s something worth including.

wget -O /home/cpi/
chmod +x /home/cpi/

Here’s a great addition to allow you to select base game and mod independently! :slight_smile:

1 Like

Ok thanks for the explanation I didn’t know that about the image.

Nice if you could include it (zdoom) on the image.

I think pretty much all is looking good, I think the next release will be a great step further. Maybe I will change to be my main SD card.

Talking about retroarch, I think, well for me in this little screen, I will stick to the rgui interface, just to read better all the menu and options.

1 Like

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