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)

[javelinface]

Pretty much why I’m here, to keep hype up! And hopefully people who know more about what they’re doing will jump back on.
I initially thought the 5.4.20 kernel was a stock standard kernel without an overclock, and was using a different 5.5 kernel for overclock testing.

That’s when it occurred to me to actually check the about page, where I saw that I was in fact running at 1.4GHz the whole time on the 5.4.20 kernel. I adjusted the title of the thread accordingly.
From what I can see the battery life hasn’t been affected that much. Pretty much my attention span wavers before my battery does. I’m just using a stock battery in a stock gameshell. I’ve been pretty much tinkering with the gameshell all morning today, messing with the DS emulator (which might I add runs PERFECTLY!)
It’s easy enough to change the settings re: kernel during the make phase of the kernel development. I could I suppose release a version with a slower clock speed, but honestly, the stability gains from it far outweighed the potential battery savings.

For example, prior to overclocking, when trying different shaders out, occasionally retroarch would just outright crash when choosing just scrolling through the menus.
The biggest gains are definitely in the MAME department. Games with choppy audio now run super smooth, with properly synced up audio. I would get occasional audio buffer problems with duke nukes 3D. Now the audio remains on track.

So in a sense, having the overclock certainly helped more with things no longer being broken. But I definitely need other people’s help testing it! The current build is just that; A test build. I don’t even know if Buster may have broken something else I’m not aware of. As far as my use is concerned, it is seemingly all good!

If you have time and a spare card, please test everything out, and make sure that emulators aren’t broken, and that drivers are set up correctly. That’s one thing that I’m constantly trying to tweak. Essentially, trying to get as much of an “out of the box working” experience.
I’m sure that with the DS emulation being as good as it is, interest may pique! We shall see!

Re: Starting from scratch at each update, you don’t actually need to! I usually document each change that I make, so that if you wanted, you could replicate it on your own device. The latest updates are super straight forward and easy to do on any image. Initially I was going to switch to having future updates only being hot fixes, patches and upgrades. I may yet change my mind!

Good to hear from you again!

[r043v]

clock speed can be adjusted at run time like cpu core numbers & speed governor, have a look at cpupower package

you could use fantasti aside to select speed / cores / governor or made a tiny tool dedicated for that

you could also do it by command line, and better, tweak each sh launch script to set a power dedicated for each program,
by example, gpsp run pretty fine at 600mhz on 2 cores

for governors “schedutil” is a great one to put as default, who will live set cpu power depending on the load, this one will be the default in linux future

[adcockm]

I’ll give it a go, hopefully in the next few days.

My “starting from scratch” comment was more about my own stuff. I’d grabbed lots of different projects from git, and installed lots of dependencies for various things to either build or run stuff I was tinkering with. I still have it all on the other image, and I need to just tar it up and transfer it out and then wipe that card. The filesystem stuff is easy to backup and transfer to another card. It’s all the dependencies and configuration changes that I pretty much lose. All are documented somewhere (on the web, or in git for each project), but it takes time to track them down and set them up. I guess the main problem is I went a little wild trying lots of stuff. I know some of it counted as failed experiments, so I might just ignore that stuff for now. I also wrote some scripts and things to automate some of it (especially the box86 builds and testing), but there’s still a lot of setup stuff I’ll need to do.

I need to check my most recent card, but I’m pretty sure I was just running your previous DEOT, and moved my Pico-8 stuff over (I have a pretty extensive cache of “favorites” that I always migrate), and played around a bit with some of the emulators. I don’t think I spent any significant time migrating over other projects. So I think I can can just back up my Pico-8 stuff and maybe a few other things, and then wipe that card and install this new version. Then I can migrate stuff to it instead of this current one. And I might wait a bit to migrate the extra stuff in case there’s a more “final” version of this image.

[javelinface]

Haha! I try to be as communicative with what’s on my schedule re: releases. The next few things are going to be super easy go just install. Ie emulators, possibly a modified kernel to copy over. Nothing ground breaking.

Most of the things I do change are just reflections of pull requests that come up on GitHub. Eg, the change to use the TWM windows manager. Probably the biggest change was the recent Buster upgrade.

Another thing I could potentially include are pre installed tools for cross compiling, and other tool chains used for building kernels etc. I have a separate image with a bunch of them all installed. Haha this is probably like your image @adcockm, with a whole bunch of failed experiment breadcrumbs left behind. I too would hate to have to start this image from scratch.

They don’t take up much space and could be a welcome move to have people learn about how to set their own kernels up to tweak the gameshell. Ie, you would be able to alter the clock speeds and governors to your heart’s content. But again, this may not be for everyone. I’d have to put out a general vote.

The one thing that might be a bit more cumbersome is eventually copying over the contents of ~/launcher/sys.py/UI that are what makes the contents of the custom DEOT settings pages tick. But that’s purely aesthetic. Not something that is high on the list. Just I know there will be those out there wanting a carbon copy upgraded version of the stock DEOT OS.

@r043v If you did have a tool that can be used to change clocks and governors, that would be amazing! I’d even say, altering the settings page within the stock Clockwork OS to include it would be a viable option!
Once I get that hang of how to use Arch more, I’d be very keen to help out with any progress and or testing.

There seem to be a plethora of resources beyond the forums covering arch. The current stock clockwork “awesome” launcher is visually very nice, and feels solid, but for the average person to easily tinker with, certainly requires a lot of fiddling and fussing.

Arch seems like more of a non nonsense no frills business structure. I guess this custom OS is almost the opposite, what with the focus on visual appeal, and the inclusion of extra emulators/tools etc.

[podmaz]

Hello, @javelinface
Can you create an instruction on how to install and config SCUMMVM on stock firmware?

[javelinface]

Sure! In a nutshell, just install it using sudo apt-get install scummvm
The problem is, scumVM requires you to use an F5 key to access the menu to quit. There’s no way to remap this within the app, so you’ll be stuck trying to return to the launcher without restarting.

You’ll need to either need to use xmodmap (it’s already installed on stock 0.5 AFAIK) to change the mapping of an existing key to F5 (oh wow why didn’t I think of that before? I might just do that!) or do what I initially did, and install xbindkeys (sudo apt-get install xbindkeys) or something similar to invoke a kill switch to terminate scummVM, return your binding to normal and terminate xbindkeys.

I made a file ~/.bindscummvm containing:

"killall scummvm && xbindkeys --defaults > ~/.xbindkeysrc && killall xbindkeys"
l + h + o + y

Looking back, I was lazy. I might actually make an xmodmap instead, in addition to the xbindkeys. From here, just make a scummvm.sh menu entry (and an icon if you wish) where you want (writing the executable bit {chmod +x}) referencing the above changes on launch. Since it’s installed properly to the usr space, you can invoke it using the command scummvm

Here are my scummvm.sh file contents:

#!/bin/bash

xbindkeys -f ~/.bindscummvm
scummvm --joystick

I also included the parameter --joystick in case people haven’t flashed the mouse firmware to their arduino keyboard. However since the keyboard is essentially well, a keyboard and not a joystick I’m not sure if it actually does anything.

Oh that’s another thing. Flash the mouse custom firmware to the arduino keyboard.

Currently I have it set to SHIFT+ABXY (LHOY) mash as the exit key combo. Not exactly eloquent, but better than holding the power button!

I was actually thinking of using this key combo as a universal kill switch for whatever app is currently in the foreground, ie kinda like the old game boy AB+start+select soft reset key combo.

Now. I’m not sure if you’ll need to install any extra dependencies for running midi on a stock firmware. I just know that I installed a bunch of things to get midi working while installing Zdoom. Ooh good thing you brought this to my attention. I’ve only tested ScummVM on my own day to day image with zdoom installed. The one currently up for download doesn’t have it, since it didn’t receive many votes when I put up a poll.
It might be easier if you just install Zdoom along with its dependencies if sound isn’t working in ScummVM.
Check out this script
Probably just pick and choose between these:

 sudo apt-get -y install g++ make cmake libsdl2-dev git zlib1g-dev libbz2-dev libjpeg-dev libfluidsynth-dev libgme-dev libopenal-dev libmpg123-dev libsndfile1-dev libwildmidi-dev libgtk-3-dev timidity nasm tar chrpath patchelf

From here, you shouldn’t need go touch any of the sound settings in ScummVM. You may want to adjust the graphics mode to “Normal (no scaling)” to make the menu readable from the Gameshell screen.

Of course, all this will be way easier if you just downloaded my community image, but I can understand not wanting to start from scratch. Man I should really just find a way to have a patch to upgrade an existing 0.5 installation to incrementally include whatever things people want. The dream. That seems to be the biggest grip against people using this community image.

[podmaz]

Graet! Thank you! @javelinface

[javelinface]

New image incoming! Sorry for being so close to the last one. I’m going to assume that since there have been about 20 downloads of the previous 200307 build and no detrimental problems reported back that the Buster upgrade I previously did was a success. I’ll be moving on ahead and using this as the base from now on.

DEOT v2+ Build 200313
13th of March 2020

Current changes:

1. Stripped the first 1M from the stock DEOT image to finally have the proper first boot screen
2. Installed and configured Drastic DS Standalone emulator and made DS ROM directory
3. Installed and configured OhBoy Gameboy Standalone emulator
4. Installed and configured Fceux NES Standalone emulator
5. Made launcher menu item for FBA Arcade and made FBA ROM directory
6. Made launcher menu item for Wswan Wonderswan and made WSWAN ROM directory
7. Emptied the mail
8. Removed the stray kernel building files
9. Did a general update of retroarch cores, assets, shaders, etc.
10. Clockspeed reporting back to being stock 1008.0 MHz

The download link is in the first post:

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)

Similar to my previous DEOT custom build based on 0.4, I have put together a new image, based on the ClockWork OS 0.5. This is the same as the official 0.5 image, just with a lot of updates, and quality of experience optimisations. You don’t need the DEOT edition Gameshell to use this. The official DEOT image is much older, and behind the official 0.5 image. This custom image is the bridge to get the best of both worlds. [b7d679edaee7a55ad42147c9085b5e919824296a_2_462x500] Here is a google dr…

[i4s33u]

thanks for your work. I’ve just flashed build 200313 and it worked out of the box. Now I will copy back our ROMs from 200307 and test them out.
One question: how can I check for CPU temperature? cat /sys/devices/virtual/thermal/thermal_zone0/temp gave me Invalid Argument error

I’d like to monitor my CPU temp to decide if it’s necessary to apply some cooling mods. Currently I had a heat sink applied on top of R16 chip, but the board case looks too tight for air to coming in and out.

[javelinface]

Hello! Welcome to the forums!

I’ll have to check if I have the temperature sensors enabled in the kernel. It’s not something that comes stock. I’m currently using this just with a modified splash screen.
I’ll roll together a modified ones with temp sensors if you’re using them. There’s a 5.4.21 out by the same author. I think it’s @shell.
Let me know what your temp sensor mods are too! I’d love to include them in a future release.

[jarze]

Thanks for sharing your custom image.
Just one question. I find out that when I am lunching GameShell, my screen does not refresh well.
After a minute, everything back to normal. I am just wondering if someone else had a similar issue?

[javelinface]

Hello! Welcome to the forums!
Do you mean, a minute as in 60 seconds, or the figurative way of saying “a minute” being a few seconds after entering the launcher?
Are you referring to the refresh rate of the launcher, refresh rate of an emulator, or some kind of V-Sync issue within either?
Unfortunately I can’t see what your image you posted is. it’s just a thumbnail of an image.

Another thing it could be is the governor kicking in, changing the clock speed. Either that or the IO scheduler. That said, it shouldn’t fluctuate enough to have a visible change in clock frequency. Also, on build, the kernel was set to use the Performance governor, which should be having the clock speed fairly consistent.


Perhaps it could be something to do with background processes starting up. That said, I don’t experience this screen not refreshing well. I guess for now, if you could clarify what your symptoms are, I can look into it more.
For now, I’ll try writing my image to a completely different card. I use the stock grey and white 16GB cards that come with the Gameshell to test, since that is something I know that everyone has in common.

I was thinking of potentially using a different governor, but since the kernel config wasn’t made by me, i felt it disrespectful to the author to change things from stock. That said, I did change the boot splash screen. But that was something that was included as a stock Clockwork Pi asset. A lot of moral issues haha!

I suppose I could change up the kernel a bit, using a different governor, turn off all debugging features, and anything else that people might want changed.

One more thing! Is this something you experience with the stock 0.5 image too?

[jarze]

Hello
Thank you for a quick response.
Please find below to link with better quality videos
https://drive.google.com/drive/folders/1wuA3Cov01gzMy0l9F7j6WNPe_o1hv8MZ?usp=sharing

Answering your questions:

1. by saying a minute, I wanted to highlight that the described issue disappears when I am using GameShell. I didn’t count time precisely, but I would say that issue is visible 60-120 seconds
2. "Are you referring to the refresh rate of the launcher, … " - I am referring to the launcher
3. I am using a Samsung 128GB EVO card, I also tried with Orginal GameShell SanDisk Ultra 16GB the same result.
4. I flashed both cards using Etcher (1.5.79) on my MacBook
5. " … you experience with the stock 0.5 image too" - to be honest, I didn’t try with 0.5 stock, but I am also curious If I will get the same issue. Let me try. I will come back to you.

Thanks for help
Cheers

[javelinface]

WOAH THAT IS STRANGE! I definitely don’t get anything like that!
I’m curious as to what revision board you have. It could be related.
Could you check that in settings>about, and post what it says under processor?
Both of my gameshells I’ve tested on are ARMv7 Processor rev 5 (v71).
Have you made any other mods to the system, re: battery upgrades or anything else?
Also, could you try and expand the image to take up the entire 128GB space? It should’t be the case, but it could be header related re: partition table.

For now, also try this.

Download this file.

5.4.21.zip

Decompress and copy the contents of it to /home/cpi

Mount the boot partition with sudo mount /dev/mmcblk0p1 /boot

Move the files to the boot partition with:

sudo mv uImage /boot
sudo mv sun8i-r16-clockworkpi-cpi3.dtb /boot
sudo mv sun8i-r16-clockworkpi-cpi3-hdmi.dtb /boot

Reboot with sudo reboot

[jarze]

5. Coming back to our previous discussion … you experience with the stock 0.5 image too"

• I tried to build the image on my MacBook using Etcher (1.5.79)
  when I lunch it on my GameShell, it didn’t work. I saw only an initial screen with a clockwork logo. It was looping all over time.

• then I’ve tried to create a bootable disk on windows 10 using.
  I successfully create it, and it works perfectly fine.

• I thought that if I successfully created a bootable disk on Windows, I do it the same with image DEOT v2+ Build 200313. Unfortunately, that was the wrong direction.

Coming back to your questions

1. " board you have."
   

   

2. Have you made any other mods to the system, re: battery upgrades or anything else
   nope - all parts are original

3. For now, also try this.
   I am following your instructions with below output.

cpi@clockworkpi:~$ sudo mount /dev/mmcblk0p1 /boot

cpi@clockworkpi:~$ sudo mv uImage /boot

mv: failed to preserve ownership for ‘/boot/uImage’: Operation not permitted

[javelinface]

Thanks for getting back!

5. The stock 0.5 image needs to loop a few times for the initial auto expansion. Let it sit for a few minutes and see how it goes. Although, if it’s going to show the weird refresh problems, it would show it then as well.

I personally use a program called “Apple Pi Baker” for writing images on my MacBook. Ie it’s what I used ages ago for raspberry pi purposes. Give that a go. Not sure why making a bootable disk worked, since you’re writing an image sector by sector.

1. Sounds like we have the same revision board. That said your DEOT front shell is different fo mine. Mine doesn’t have ”Dimenstional Engineering Technology” written above the speaker.

2. I’m guessing you just got the gameshell, and have never used it before. Did the stock 0.4 DEOT image have the problem? And also when you got the 0.5 image working, did it have the problem?

3. I think the file move still worked. Just ownership wasn’t preserved. It should still be there. Check the kernel version in settings>about. It should have gone up to 5.4.21. Any changes? I’ve written the image to another sandisk 32GB Card. Everything was fine. I’ll try on a 64GB and 128GB Card after work. I’m due for an upgrade anyway, what with the amount of DS and PSX emulation I’ve been doing lately.

Another thing to try is using the stock Grey and white 16GB sandisk SD card that came with the console.
I remember reading another user here (I think @adcockm) having troubles writing the stock 0.5 image to his 400GB card taking up the space.

Although not directly related, in order to get the first boot screen, I stripped the first 1M of the stock raw DEOT image and replaced them on the stock image. I’m in the process of hex editing it to determine where the start and finish of the boot splash image is, so that the partition table, and any other parts of the first 1M remain untouched.

For this reason, potentially larger SD cards become affected due to this. In testing just trimming the first 1M, I used the header from a 16GB image on a 32GB card. This resulted in a boot loop. As long as the header of the source matches the destination, seemingly all was well. If there is some extra indiscrepancy with larger SD cards, I would need to look into it further. This is why I assumed that by doing an expansion to take up the entire SD card space, the header would get updated accordingly.

I’ve just tested the same image on a 128GB Sandisk Ultra A1 card. All seems to be good. I haven’t got any A2 cards unfortunately. Hopefully someone else can test it if they use/own one.

[javelinface]

Back on topic re: progress on the image:
In summary:

1. Wonderswan icon colour fixed
2. Made SCUMMVM games directory
3. drastic.cfg modified for screen display
4. mupen64plus.cfg modified with updated keybindings for C buttons
5. Kernel 5.5.9 tested, and 1400MHz overclock tested.
6. Include script to test out kernel and dtb clock settings, and change back
7. Slight palette change to desktopbg.jpg to match the overall DEOT feel.
8. Removal of LauncherGo and settings list item.

More info

1. I made a change to the skin file slightly, for those wanting to just incrementally download things themselves. A small colour change to the Wonderswan icon, since the blue was a little bit off. Also, updating the main skin with all of the most current changes.
   https://drive.google.com/open?id=1nGaprKSo875NLkASRDpUkXUR4atnkD7F

2. I forgot to add a directory called “SCUMMVM” in /home/cpi/games/
   Just add that, and then add SCUMMVM games to that if you use it.

3. I also modified the drastic.cfg file slightly, after realising that some games on DS prefer to have the bottom screen as the main display, eg Dragon Quest VI. Some other DS games also have the screens tiled. I simply changed the behaviour of the screen switch using shift + A/B.

frameskip_type = 2
frameskip_value = 4
show_frame_counter = 0
screen_orientation = 2
screen_scaling = 2
screen_swap = 0
savestate_number = 0
fast_forward = 0
enable_sound = 1
clock_speed = 0
threaded_3d = 1
mirror_touch = 0
compress_savestates = 1
savestate_snapshot = 1
unzip_roms = 1
backup_in_savestates = 1
ignore_gamecard_limit = 0
frame_interval = 0
trim_roms = 1
fix_main_2d_screen = 0
disable_edge_marking = 0
hires_3d = 0
use_rtc_custom_time = 0
rtc_custom_time = 0
rtc_system_time = 0
firmware.username = DEOT
firmware.language = 1
firmware.favorite_color = 0
firmware.birthday_month = 1
firmware.birthday_day = 2
enable_cheats = 1
controls_a[CONTROL_INDEX_UP] = 338
controls_a[CONTROL_INDEX_DOWN] = 337
controls_a[CONTROL_INDEX_LEFT] = 336
controls_a[CONTROL_INDEX_RIGHT] = 335
controls_a[CONTROL_INDEX_A] = 107
controls_a[CONTROL_INDEX_B] = 106
controls_a[CONTROL_INDEX_X] = 105
controls_a[CONTROL_INDEX_Y] = 117
controls_a[CONTROL_INDEX_L] = 121
controls_a[CONTROL_INDEX_R] = 111
controls_a[CONTROL_INDEX_START] = 13
controls_a[CONTROL_INDEX_SELECT] = 32
controls_a[CONTROL_INDEX_HINGE] = 8
controls_a[CONTROL_INDEX_TOUCH_CURSOR_UP] =
controls_a[CONTROL_INDEX_TOUCH_CURSOR_DOWN] =
controls_a[CONTROL_INDEX_TOUCH_CURSOR_LEFT] =
controls_a[CONTROL_INDEX_TOUCH_CURSOR_RIGHT] =
controls_a[CONTROL_INDEX_TOUCH_CURSOR_PRESS] =
controls_a[CONTROL_INDEX_MENU] = 8
controls_a[CONTROL_INDEX_SAVE_STATE] =
controls_a[CONTROL_INDEX_LOAD_STATE] =
controls_a[CONTROL_INDEX_FAST_FORWARD] = 
controls_a[CONTROL_INDEX_SWAP_SCREENS] = 108
controls_a[CONTROL_INDEX_SWAP_ORIENTATION_A] = 
controls_a[CONTROL_INDEX_SWAP_ORIENTATION_B] = 104
controls_a[CONTROL_INDEX_LOAD_GAME] =
controls_a[CONTROL_INDEX_QUIT] =
controls_a[CONTROL_INDEX_UI_UP] = 338
controls_a[CONTROL_INDEX_UI_DOWN] =337
controls_a[CONTROL_INDEX_UI_LEFT] = 336
controls_a[CONTROL_INDEX_UI_RIGHT] = 335
controls_a[CONTROL_INDEX_UI_SELECT] = 107
controls_a[CONTROL_INDEX_UI_BACK] = 106
controls_a[CONTROL_INDEX_UI_EXIT] = 27
controls_a[CONTROL_INDEX_UI_PAGE_UP] = 111
controls_a[CONTROL_INDEX_UI_PAGE_DOWN] = 121
controls_a[CONTROL_INDEX_UI_SWITCH] = 32
controls_b[CONTROL_INDEX_UP] =
controls_b[CONTROL_INDEX_DOWN] =
controls_b[CONTROL_INDEX_LEFT] =
controls_b[CONTROL_INDEX_RIGHT] =
controls_b[CONTROL_INDEX_A] =
controls_b[CONTROL_INDEX_B] =
controls_b[CONTROL_INDEX_X] =
controls_b[CONTROL_INDEX_Y] =
controls_b[CONTROL_INDEX_L] =
controls_b[CONTROL_INDEX_R] =
controls_b[CONTROL_INDEX_START] =
controls_b[CONTROL_INDEX_SELECT] =
controls_b[CONTROL_INDEX_HINGE] =
controls_b[CONTROL_INDEX_TOUCH_CURSOR_UP] =
controls_b[CONTROL_INDEX_TOUCH_CURSOR_DOWN] =
controls_b[CONTROL_INDEX_TOUCH_CURSOR_LEFT] =
controls_b[CONTROL_INDEX_TOUCH_CURSOR_RIGHT] =
controls_b[CONTROL_INDEX_TOUCH_CURSOR_PRESS] =
controls_b[CONTROL_INDEX_MENU] =
controls_b[CONTROL_INDEX_SAVE_STATE] =
controls_b[CONTROL_INDEX_LOAD_STATE] =
controls_b[CONTROL_INDEX_FAST_FORWARD] =
controls_b[CONTROL_INDEX_SWAP_SCREENS] =
controls_b[CONTROL_INDEX_SWAP_ORIENTATION_A] =
controls_b[CONTROL_INDEX_SWAP_ORIENTATION_B] =
controls_b[CONTROL_INDEX_LOAD_GAME] =
controls_b[CONTROL_INDEX_QUIT] =
controls_b[CONTROL_INDEX_UI_UP] =
controls_b[CONTROL_INDEX_UI_DOWN] =
controls_b[CONTROL_INDEX_UI_LEFT] =
controls_b[CONTROL_INDEX_UI_RIGHT] =
controls_b[CONTROL_INDEX_UI_SELECT] =
controls_b[CONTROL_INDEX_UI_BACK] =
controls_b[CONTROL_INDEX_UI_EXIT] =
controls_b[CONTROL_INDEX_UI_PAGE_UP] =
controls_b[CONTROL_INDEX_UI_PAGE_DOWN] =
controls_b[CONTROL_INDEX_UI_SWITCH] =

If you haven’t already installed Drastic, give it a go. It works very well. See this post:
Desmume or MelonDS

4. I’ve also modified the controls of mupen a little bit, just to make the C buttons match up more with the shift + ABXY buttons. C-Up and C-Down were mixed up.

# Mupen64Plus Configuration File
# This file is automatically read and written by the Mupen64Plus Core library

[64DD]

# Filename of the 64DD IPL ROM
IPL-ROM = ""
# Filename of the disk to load into Disk Drive
Disk = ""


[Audio-SDL]

# Mupen64Plus SDL Audio Plugin config parameter version number
Version = 1.000000
# Frequency which is used if rom doesn't want to change it
DEFAULT_FREQUENCY = 33600
# Swaps left and right channels
SWAP_CHANNELS = False
# Size of primary buffer in output samples. This is where audio is loaded after it's extracted from n64's memory.
PRIMARY_BUFFER_SIZE = 16384
# Fullness level target for Primary audio buffer, in equivalent output samples. This value must be larger than the SECONDARY_BUFFER_SIZE. Decreasing this value will reduce audio latency but requires a faster PC to avoid choppiness. Increasing this will increase audio latency but reduce the chance of drop-outs.
PRIMARY_BUFFER_TARGET = 2048
# Size of secondary buffer in output samples. This is SDL's hardware buffer. The SDL documentation states that this should be a power of two between 512 and 8192.
SECONDARY_BUFFER_SIZE = 1024
# Audio resampling algorithm. src-sinc-best-quality, src-sinc-medium-quality, src-sinc-fastest, src-zero-order-hold, src-linear, speex-fixed-{10-0}, trivial
RESAMPLE = "trivial"
# Volume control type: 1 = SDL (only affects Mupen64Plus output)  2 = OSS mixer (adjusts master PC volume)
VOLUME_CONTROL_TYPE = 1
# Percentage change each time the volume is increased or decreased
VOLUME_ADJUST = 5
# Default volume when a game is started.  Only used if VOLUME_CONTROL_TYPE is 1
VOLUME_DEFAULT = 80
# Synchronize Video/Audio
AUDIO_SYNC = False


[Core]

# Mupen64Plus Core config parameter set version number.  Please don't change this version number.
Version = 1.010000
# Draw on-screen display if True, otherwise don't draw OSD
OnScreenDisplay = False
# Use Pure Interpreter if 0, Cached Interpreter if 1, or Dynamic Recompiler if 2 or more
R4300Emulator = 2
# Disable compiled jump commands in dynamic recompiler (should be set to False)
NoCompiledJump = False
# Disable 4MB expansion RAM pack. May be necessary for some games
DisableExtraMem = True
# Increment the save state slot after each save operation
AutoStateSlotIncrement = False
# Activate the R4300 debugger when ROM execution begins, if core was built with Debugger support
EnableDebugger = False
# Save state slot (0-9) to use when saving/loading the emulator state
CurrentStateSlot = 0
# Path to directory where screenshots are saved. If this is blank, the default value of ${UserDataPath}/screenshot will be used
ScreenshotPath = ""
# Path to directory where emulator save states (snapshots) are saved. If this is blank, the default value of ${UserDataPath}/save will be used
SaveStatePath = ""
# Path to directory where SRAM/EEPROM data (in-game saves) are stored. If this is blank, the default value of ${UserDataPath}/save will be used
SaveSRAMPath = ""
# Path to a directory to search when looking for shared data files
SharedDataPath = ""
# Force number of cycles per emulated instruction
CountPerOp = 0
# Randomize PI/SI Interrupt Timing
RandomizeInterrupt = True
# Duration of SI DMA (-1: use per game settings)
SiDmaDuration = -1
# Gameboy Camera Video Capture backend
GbCameraVideoCaptureBackend1 = ""


[CoreEvents]

# Mupen64Plus CoreEvents config parameter set version number.  Please don't change this version number.
Version = 1.000000
# SDL keysym for stopping the emulator
Kbd Mapping Stop = 8
# SDL keysym for switching between fullscreen/windowed modes
Kbd Mapping Fullscreen = 0
# SDL keysym for saving the emulator state
Kbd Mapping Save State = 269
# SDL keysym for loading the emulator state
Kbd Mapping Load State = 270
# SDL keysym for advancing the save state slot
Kbd Mapping Increment Slot = 0
# SDL keysym for resetting the emulator
Kbd Mapping Reset = 290
# SDL keysym for slowing down the emulator
Kbd Mapping Speed Down = 291
# SDL keysym for speeding up the emulator
Kbd Mapping Speed Up = 292
# SDL keysym for taking a screenshot
Kbd Mapping Screenshot = 293
# SDL keysym for pausing the emulator
Kbd Mapping Pause = 112
# SDL keysym for muting/unmuting the sound
Kbd Mapping Mute = 109
# SDL keysym for increasing the volume
Kbd Mapping Increase Volume = 93
# SDL keysym for decreasing the volume
Kbd Mapping Decrease Volume = 91
# SDL keysym for temporarily going really fast
Kbd Mapping Fast Forward = 27
# SDL keysym for advancing by one frame when paused
Kbd Mapping Frame Advance = 47
# SDL keysym for pressing the game shark button
Kbd Mapping Gameshark = 103
# Joystick event string for stopping the emulator
Joy Mapping Stop = ""
# Joystick event string for switching between fullscreen/windowed modes
Joy Mapping Fullscreen = ""
# Joystick event string for saving the emulator state
Joy Mapping Save State = ""
# Joystick event string for loading the emulator state
Joy Mapping Load State = ""
# Joystick event string for advancing the save state slot
Joy Mapping Increment Slot = ""
# Joystick event string for resetting the emulator
Joy Mapping Reset = ""
# Joystick event string for slowing down the emulator
Joy Mapping Speed Down = ""
# Joystick event string for speeding up the emulator
Joy Mapping Speed Up = ""
# Joystick event string for taking a screenshot
Joy Mapping Screenshot = ""
# Joystick event string for pausing the emulator
Joy Mapping Pause = ""
# Joystick event string for muting/unmuting the sound
Joy Mapping Mute = ""
# Joystick event string for increasing the volume
Joy Mapping Increase Volume = ""
# Joystick event string for decreasing the volume
Joy Mapping Decrease Volume = ""
# Joystick event string for fast-forward
Joy Mapping Fast Forward = ""
# Joystick event string for advancing by one frame when paused
Joy Mapping Frame Advance = ""
# Joystick event string for pressing the game shark button
Joy Mapping Gameshark = ""


[Input-SDL-Control1]

# Mupen64Plus SDL Input Plugin config parameter version number.  Please don't change this version number.
version = 2.000000
# Controller configuration mode: 0=Fully Manual, 1=Auto with named SDL Device, 2=Fully automatic
mode = 0
# Specifies which joystick is bound to this controller: -1=No joystick, 0 or more= SDL Joystick number
device = -1
# SDL joystick name (or Keyboard)
name = "Keyboard"
# Specifies whether this controller is 'plugged in' to the simulated N64
plugged = True
# Specifies which type of expansion pak is in the controller: 1=None, 2=Mem pak, 4=Transfer pak, 5=Rumble pak
plugin = 2
# If True, then mouse buttons may be used with this controller
mouse = False
# Scaling factor for mouse movements.  For X, Y axes.
MouseSensitivity = "2.00,2.00"
# The minimum absolute value of the SDL analog joystick axis to move the N64 controller axis value from 0.  For X, Y axes.
AnalogDeadzone = "4096,4096"
# An absolute value of the SDL joystick axis >= AnalogPeak will saturate the N64 controller axis value (at 80).  For X, Y axes. For each axis, this must be greater than the corresponding AnalogDeadzone value
AnalogPeak = "32768,32768"
# Digital button configuration mappings
DPad R = "key(100)"
DPad L = "key(97)"
DPad D = "key(115)"
DPad U = "key(119)"
Start = "key(13)"
Z Trig = "key(105)"
B Button = "key(117)"
A Button = "key(106)"
C Button R = "key(108)"
C Button L = "key(121)"
C Button D = "key(104)"
C Button U = "key(111)"
R Trig = "key(107)"
L Trig = "key(32)"
Mempak switch = "key(44)"
Rumblepak switch = "key(46)"
# Analog axis configuration mappings
X Axis = "key(276,275)"
Y Axis = "key(273,274)"


[Input-SDL-Control2]

# Mupen64Plus SDL Input Plugin config parameter version number.  Please don't change this version number.
version = 2.000000
# Controller configuration mode: 0=Fully Manual, 1=Auto with named SDL Device, 2=Fully automatic
mode = 2
# Specifies which joystick is bound to this controller: -1=No joystick, 0 or more= SDL Joystick number
device = -1
# SDL joystick name (or Keyboard)
name = ""
# Specifies whether this controller is 'plugged in' to the simulated N64
plugged = False
# Specifies which type of expansion pak is in the controller: 1=None, 2=Mem pak, 4=Transfer pak, 5=Rumble pak
plugin = 2
# If True, then mouse buttons may be used with this controller
mouse = False
# Scaling factor for mouse movements.  For X, Y axes.
MouseSensitivity = "2.00,2.00"
# The minimum absolute value of the SDL analog joystick axis to move the N64 controller axis value from 0.  For X, Y axes.
AnalogDeadzone = "4096,4096"
# An absolute value of the SDL joystick axis >= AnalogPeak will saturate the N64 controller axis value (at 80).  For X, Y axes. For each axis, this must be greater than the corresponding AnalogDeadzone value
AnalogPeak = "32768,32768"
# Digital button configuration mappings
DPad R = ""
DPad L = ""
DPad D = ""
DPad U = ""
Start = ""
Z Trig = ""
B Button = ""
A Button = ""
C Button R = ""
C Button L = ""
C Button D = ""
C Button U = ""
R Trig = ""
L Trig = ""
Mempak switch = ""
Rumblepak switch = ""
# Analog axis configuration mappings
X Axis = ""
Y Axis = ""


[Input-SDL-Control3]

# Mupen64Plus SDL Input Plugin config parameter version number.  Please don't change this version number.
version = 2.000000
# Controller configuration mode: 0=Fully Manual, 1=Auto with named SDL Device, 2=Fully automatic
mode = 2
# Specifies which joystick is bound to this controller: -1=No joystick, 0 or more= SDL Joystick number
device = -1
# SDL joystick name (or Keyboard)
name = ""
# Specifies whether this controller is 'plugged in' to the simulated N64
plugged = False
# Specifies which type of expansion pak is in the controller: 1=None, 2=Mem pak, 4=Transfer pak, 5=Rumble pak
plugin = 2
# If True, then mouse buttons may be used with this controller
mouse = False
# Scaling factor for mouse movements.  For X, Y axes.
MouseSensitivity = "2.00,2.00"
# The minimum absolute value of the SDL analog joystick axis to move the N64 controller axis value from 0.  For X, Y axes.
AnalogDeadzone = "4096,4096"
# An absolute value of the SDL joystick axis >= AnalogPeak will saturate the N64 controller axis value (at 80).  For X, Y axes. For each axis, this must be greater than the corresponding AnalogDeadzone value
AnalogPeak = "32768,32768"
# Digital button configuration mappings
DPad R = ""
DPad L = ""
DPad D = ""
DPad U = ""
Start = ""
Z Trig = ""
B Button = ""
A Button = ""
C Button R = ""
C Button L = ""
C Button D = ""
C Button U = ""
R Trig = ""
L Trig = ""
Mempak switch = ""
Rumblepak switch = ""
# Analog axis configuration mappings
X Axis = ""
Y Axis = ""


[Input-SDL-Control4]

# Mupen64Plus SDL Input Plugin config parameter version number.  Please don't change this version number.
version = 2.000000
# Controller configuration mode: 0=Fully Manual, 1=Auto with named SDL Device, 2=Fully automatic
mode = 2
# Specifies which joystick is bound to this controller: -1=No joystick, 0 or more= SDL Joystick number
device = -1
# SDL joystick name (or Keyboard)
name = ""
# Specifies whether this controller is 'plugged in' to the simulated N64
plugged = False
# Specifies which type of expansion pak is in the controller: 1=None, 2=Mem pak, 4=Transfer pak, 5=Rumble pak
plugin = 2
# If True, then mouse buttons may be used with this controller
mouse = False
# Scaling factor for mouse movements.  For X, Y axes.
MouseSensitivity = "2.00,2.00"
# The minimum absolute value of the SDL analog joystick axis to move the N64 controller axis value from 0.  For X, Y axes.
AnalogDeadzone = "4096,4096"
# An absolute value of the SDL joystick axis >= AnalogPeak will saturate the N64 controller axis value (at 80).  For X, Y axes. For each axis, this must be greater than the corresponding AnalogDeadzone value
AnalogPeak = "32768,32768"
# Digital button configuration mappings
DPad R = ""
DPad L = ""
DPad D = ""
DPad U = ""
Start = ""
Z Trig = ""
B Button = ""
A Button = ""
C Button R = ""
C Button L = ""
C Button D = ""
C Button U = ""
R Trig = ""
L Trig = ""
Mempak switch = ""
Rumblepak switch = ""
# Analog axis configuration mappings
X Axis = ""
Y Axis = ""


[Rsp-HLE]

# Mupen64Plus RSP HLE Plugin config parameter version number
Version = 1.000000
# Path to a RSP plugin which will be used when encountering an unknown ucode.You can disable this by letting an empty string.
RspFallback = ""
# Send display lists to the graphics plugin
DisplayListToGraphicsPlugin = True
# Send audio lists to the audio plugin
AudioListToAudioPlugin = False


[Transferpak]

# Filename of the GB ROM to load into transferpak 1
GB-rom-1 = ""
# Filename of the GB RAM to load into transferpak 1
GB-ram-1 = ""
# Filename of the GB ROM to load into transferpak 2
GB-rom-2 = ""
# Filename of the GB RAM to load into transferpak 2
GB-ram-2 = ""
# Filename of the GB ROM to load into transferpak 3
GB-rom-3 = ""
# Filename of the GB RAM to load into transferpak 3
GB-ram-3 = ""
# Filename of the GB ROM to load into transferpak 4
GB-rom-4 = ""
# Filename of the GB RAM to load into transferpak 4
GB-ram-4 = ""


[UI-Console]

# Mupen64Plus UI-Console config parameter set version number.  Please don't change this version number.
Version = 1.000000
# Directory in which to search for plugins
PluginDir = "/usr/local/lib/mupen64plus/"
# Filename of video plugin
VideoPlugin = "mupen64plus-video-rice.so"
# Filename of audio plugin
AudioPlugin = "mupen64plus-audio-sdl.so"
# Filename of input plugin
InputPlugin = "mupen64plus-input-sdl.so"
# Filename of RSP plugin
RspPlugin = "mupen64plus-rsp-hle.so"


[Video-General]

# Use fullscreen mode if True, or windowed mode if False
Fullscreen = True
# Width of output window or fullscreen width
ScreenWidth = 320
# Height of output window or fullscreen height
ScreenHeight = 240
# If true, activate the SDL_GL_SWAP_CONTROL attribute
VerticalSync = True


[Video-Rice]

# Mupen64Plus Rice Video Plugin config parameter version number
Version = 1
# Frame Buffer Emulation (0=ROM default, 1=disable)
FrameBufferSetting = 0
# Frequency to write back the frame buffer (0=every frame, 1=every other frame, etc)
FrameBufferWriteBackControl = 0
# Render-to-texture emulation (0=none, 1=ignore, 2=normal, 3=write back, 4=write back and reload)
RenderToTexture = 4
# Control when the screen will be updated (0=ROM default, 1=VI origin update, 2=VI origin change, 3=CI change, 4=first CI change, 5=first primitive draw, 6=before screen clear, 7=after screen drawn)
ScreenUpdateSetting = 4
# Force to use normal alpha blender
NormalAlphaBlender = False
# Use a faster algorithm to speed up texture loading and CRC computation
FastTextureLoading = False
# Use different texture coordinate clamping code
AccurateTextureMapping = False
# Force emulated frame buffers to be in N64 native resolution
InN64Resolution = 3
# Try to reduce Video RAM usage (should never be used)
SaveVRAM = False
# Enable this option to have better render-to-texture quality
DoubleSizeForSmallTxtrBuf = 4
# Force to use normal color combiner
DefaultCombinerDisable = False
# Enable game-specific settings from INI file
EnableHacks = False
# If enabled, graphics will be drawn in WinFrame mode instead of solid and texture mode
WinFrameMode = False
# N64 Texture Memory Full Emulation (may fix some games, may break others)
FullTMEMEmulation = False
# Enable vertex clipper for fog operations
OpenGLVertexClipper = False
# Enable/Disable SSE optimizations for capable CPUs
EnableSSE = True
# If this option is enabled, the plugin will skip every other frame
SkipFrame = False
# If enabled, texture enhancement will be done only for TxtRect ucode
TexRectOnly = False
# If enabled, texture enhancement will be done only for textures width+height<=128
SmallTextureOnly = False
# Select hi-resolution textures based only on the CRC and ignore format+size information (Glide64 compatibility)
LoadHiResCRCOnly = True
# Enable hi-resolution texture file loading
LoadHiResTextures = False
# Enable texture dumping
DumpTexturesToFiles = False
# Display On-screen FPS
ShowFPS = False
# Use Mipmapping? 0=no, 1=nearest, 2=bilinear, 3=trilinear
Mipmapping = 0
# Enable, Disable fog generation (0=Disable, 1=Enable)
FogMethod = 0
# Force to use texture filtering or not (0=auto: n64 choose, 1=force no filtering, 2=force filtering)
ForceTextureFilter = 0
# Primary texture enhancement filter (0=None, 1=2X, 2=2XSAI, 3=HQ2X, 4=LQ2X, 5=HQ4X, 6=Sharpen, 7=Sharpen More, 8=External, 9=Mirrored)
TextureEnhancement = 0
# Secondary texture enhancement filter (0 = none, 1-4 = filtered)
TextureEnhancementControl = 0
# Color bit depth to use for textures (0=default, 1=32 bits, 2=16 bits)
TextureQuality = 2
# Z-buffer depth (only 16 or 32)
OpenGLDepthBufferSetting = 16
# Enable/Disable MultiSampling (0=off, 2,4,8,16=quality)
MultiSampling = 0
# Color bit depth for rendering window (0=32 bits, 1=16 bits)
ColorQuality = 0
# OpenGL level to support (0=auto, 1=OGL_FRAGMENT_PROGRAM)
OpenGLRenderSetting = 0
# Enable/Disable Anisotropic Filtering for Mipmapping (0=no filtering, 2-16=quality). This is uneffective if Mipmapping is 0. If the given value is to high to be supported by your graphic card, the value will be the highest value your graphic card can support. Better result with Trilinear filtering
AnisotropicFiltering = 0
# If true, use polygon offset values specified below
ForcePolygonOffset = False
# Specifies a scale factor that is used to create a variable depth offset for each polygon
PolygonOffsetFactor = 0.000000
# Is multiplied by an implementation-specific value to create a constant depth offset
PolygonOffsetUnits = 0.000000

5. I’m mucking around with the 5.5.9 kernel, just to see how the schedutil governor behaves.
   Hopefully we can get 1400GHz to be somewhat standardised and not be too much of a power drain.
   Running 5.5.9 at 1400MHz is very nice. Without the OC, dragon quest VI on DS runs very choppy at times, especially with fog. Likewise, banjo Kazooie has slow downs when too many models appear on screen at once. The kernel/OC combo basically addresses both. Zelda Ocarina of Time on Mupen is now VERY playable.

6. I’ve made a simple script to copy whatever kernel and dtb file into the boot partition to let you set each up respectively. Maybe I should release the next version with stock speeds/kernel, with the option of enabling the newer and faster combo as a test.

Here’s a link to the small script: (Note: This is purely for testing! It is an overclock after all, and I can’t guarantee what the results of using this will be)
https://drive.google.com/open?id=1x1_jhFIaBlrRvuugzQNVMvZ25hVot4Qg
Copy the 07_Clockspeed and 08_Kernel folders to /home/cpi/apps/Menu/60_Utils/, then give all of the *.sh scripts the executable bit, ie chmod +x filename.sh (if they need it - they shouldn’t)
Running each will overwrite whatever is in your boot partition, so as a precaution backup before using this. This script doesn’t back up your original kernel/dtb file. As the name of each script would suggest, it goes between the stock Kernel versions 5.4.21 (The version on the current 2003131 build is 5.4.20, so this is a small incremental upgrade) and the current latest stable 5.5.9. I wouldn’t normally recommend using an untested new kernel; instead preferring to use old stable. But this image is about pushing limits, and testing what the newest things are.
Likewise, it has scripts for going between 1008MHz (stock) and an experimental overclocked 1400MHz. This is using the work of @Joao_Manoel as seen here: (with a few modifications, eg extra governors, custom boot screen etc.)
1.2GHz and beyond

For more information re: how to manually change clock speeds etc, check out here:
https://wiki.archlinux.org/index.php/CPU_frequency_scaling
@adcockm - That could be useful for what you were asking in this post.
Custom D.E.O.T. V2.0+/Clockwork OS v0.5 image - With customised DEOT interface, Kernel 5.4.20, Debian 10 Buster, Retroarch 1.8.4, Mupen64+ plus more! (Current build: 200313)

7. Just for contiguity, I changed the palette of the desktopbg.jpg file, normally only visible while connected via HDMI. My OCD was getting the better of me, and I needed it changed. The file goes in /home/cpi/launcher/sys.py/gameshell/wallpaper/ and also resides in /home/cpi/skins/DEOT/sys.py/gameshell/wallpaper/ but doesn’t appear to serve any function here.
   Here’s what it looks like. (it used to be an orange palette, and was clashing HORRIBLE with the DEOT colours.
   

   

8. I just loaded up the launcher go for fun. Boy was I in for a shock. Compared to the main launcher, the Launched go had some major lag issues. There was no wrap around cursor. Input would be delayed. Frame rate of moving items was very slow. I remember hearing of potential removal in a future official image. I may just take the liberty of removing it earlier, along with the removal of the “switch to launcher go” settings list item. I don’t think it will be too missed, since it hasn’t been maintained for a long time.

I don’t see this being that big an update, so won’t make an update any time soon. I’ll provide info on how to do changes, where they are somewhat significant. Eg, potential Kernel changes etc.

A lot of my evenings where I would normally rehearse and perform (I’m a musician) are freed up due to the recent pandemic etc, so I will be a lot more free to mess about with the gameshell. I’ll start focussing on getting the Settings pages to be closer to the stock DEOT image.

I’m also thinking, as good as the DEOT image is, this might be a good opportunity to make an original graphical UI. Even one based on a different launcher.

I do wonder, are most of the people who use this image a) those who own a DEOT gameshell wanting to have the DEOT theme, b) those who just like the darker theme, c) people who like the maintained features, d) people wanting a out of box pre-set up OS, e) people just wanting something different. It would be interesting to know for future releases.

Why have you chosen to download and use this custom community image?

• I’m a DEOT owner who wanted an updated DEOT OS
• I just like a darker theme
• I like to see maintained features
• I want an out of box preset OS
• I just want something different
• Other

[javelinface]

Since maintained features are a high point for this image, I will upload my progress as it happens, whenever I can. Of course, as I always have, I’ll provide instructions and thought processes so that you don’t necessarily need to download the latest one; instead applying the updates yourself.

Here we go!

DEOT v2+ Build 200318
18th of March 2020

• Wonderswan icon colour fixed
• Made SCUMMVM games directory
• drastic.cfg modified for screen display
• mupen64plus.cfg modified with updated keybindings for C buttons
• Kernel 5.5.9 tested, and 1400MHz overclock tested.
• Include script to test out kernel and dtb clock settings, and change back
• Slight palette change to desktopbg.jpg to match the overall DEOT feel.

As usual, I will upload the image to the initial post of this thread.

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)

Similar to my previous DEOT custom build based on 0.4, I have put together a new image, based on the ClockWork OS 0.5. This is the same as the official 0.5 image, just with a lot of updates, and quality of experience optimisations. You don’t need the DEOT edition Gameshell to use this. The official DEOT image is much older, and behind the official 0.5 image. This custom image is the bridge to get the best of both worlds. [b7d679edaee7a55ad42147c9085b5e919824296a_2_462x500] Here is a google dr…

Shortly after, I’ll upload it to Mega.

I haven’t removed the LauncherGo and related settings page entry, as I didn’t have time, would have rushed it, and could have made a mistake. It’s not that big a thing anyway.
Also, I’ll be shrinking my images down, zeroing the empty space, and applying an auto expand script in future as well. At the very least, it will make writing the image to SD faster.

[i4s33u]

Thanks for updating it. I wonder if I can just apply things in your previous comment instead of re-frash newest image.
I’m currently at build 200313, mainly use GS for Snes + GBA emulators and Pico-8 dev. I read your changelog and only want to try out new kernel.

One more thing, I see in your 07_Clockspeed folder, there was file named 1800, while shell script pointed to 1008.

[javelinface]

@i4s33u

One more thing, I see in your 07_Clockspeed folder, there was file named 1800, while shell script pointed to 1008.

OH. MY. GOODNESS!!! Thank you so much for pointing this out!!! Ahhh!! I would not have noticed this!!! Okay. I am going to have to reupload the image I think. This is a worthy thing. Otherwise it’s a one way street to an overclock. That said, once you go to 1400, seriously; you won’t look back. ;). I just put it there as a contingency plan, in case you did.

You 100% can just apply things from my comment. I put them there for that exact reason. I didn’t make a script based change, or something based on warehouse, because I know something will break when someone tries to apply it to an existing image with unknown variables. This way, you can see exactly what you’re doing and how you’re doing it.

I actually keep a separate card for mucking around on (it gets wiped a lot) a card kept pristine reflecting the current build, and my day to day build with a few extra games that I basically test, and modify. When they show promise to be included, they get added to my pristine gold master ready for uploading.

The good news is 200313 came with an updated Debian 10 Buster. Only because it’s what I’ve tested, but I remember reading some features included within the kernel are either available only on the current stable current Debian build, or on an SID release. You’ll have to cross reference kernel features to find out which things work with what build.

For the record, the main things I was experimenting with was different governors for CPU scaling. A couple of new ones popped up in this kernel release. What I could get from most of them however was that the launcher only appears to play nice when you have it set to performance.

I haven’t tried all of them yet, but at least with it ondemand and scedutil I would get extremely sluggish scrolling. Kind of like how slow it is when connected via HDMI. This is using both the TWM and DWM window managers. I thought that might have been the cause. I might try interactive next when I get home.

If you do decide to test further, and update to Debian 11 Bullseye, you may need to run a few extra scripts to ensure Lima drivers remain working. You can find exactly what I ran looking in /home/cpi/.bash_history. I left it there for that exact reason.

Again, thank you so much for letting me know of the typo! I knew I released it prematurely!