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.
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: https://github.com/clockworkpi/launcher/pull/309#issuecomment-583981387
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.
@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.
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.
Oh??? Is the battery actually better??? I actually thought they were the same! Now I need to check!
That said, it seems you can’t get official batteries from the store now, so I guess if you like the look of the DEOT (I realty do), it’s a good excuse. That said, having two Gameshells is expensive! But hey! It’s certainly served you well!
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.
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.
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 kernel.zip here. That’s the only thing I can think about.
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?
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:
xbindkeys installed to allow key shortcuts to exit/kill apps that don’t have easy termination processes. eg, sampler box and scummvm.
Samplerbox shortcut in utilities. (Exit it using menu key) thanks @edward
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.
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.
Cleaned up and optimised mupen configuration, and action.config to reflect using a /usr/local/bin file location.
Quake 2 shortcut removed.
Returned freedoom part 1 and 2 - I previously deleted, while culling all games.
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 skinmanager.py file.
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.
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:
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
Installed Emulationstation. It’s just not reliable/stable enough yet.
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
Oh haha, I also disappeared! My last update was a month ago! Life is… it is hard!
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.
