It is deffinitly software issue. I had same glitch when I tried this custom os or kernels from this os with official release. And I never had this issue with stock os.
2 Likes
No luck here unfortunately
Since you mentioned USB being plugged in, I had BETTER results while plugged in to power. Also, I did extend my internal power cables for more length, but I used a thicker stranded cable to extend it so there shouldnāt be ANY difference in power delivery.
This entire dilemma is quite perplexing. I even pulled everything apart and reconnected, making sure everything was connected/seated properly and that didnāt change anything.
I think this is some pretty important input! I might try flash the stock OS to see if that makes any difference when I get the chance.
1 Like
@javelinface, thanks for the updated image.
I had issue with kernel 5.7. Leaving device āidleā for a while make it freezed and unable to wake it up.
The screen went off, CPU temp went high (I couldnāt measure it because system was freezed, but touching the plastic cover felt so hot).
The default CPU governor in 5.7 was āondemandā. I think I should change it to āperformanceā in next time to see if problem can be solved. I mainly use overclock kernel (5.5). It is quite stable for me, running FF6 GBA and some arcade games very well. I only switch to 5.7 for sometime, but the last time, I left my device on with wifi and charging it. The issue occured.
It happended on @Joao_Manoelās custom image as well. So I think it could be a kernel issue.
1 Like
Yes!ā Precisely! It actually IS the same kernel as Joaoās image; albeit with the DEOT splash screen. So that is good to hear that it seems that there could be some hardware discrepancies/compatibilities directly with the kernel. Although ā¦
In this instance, when you mean software, are you referring directly and SPECIFICALLY to the OS, launcher, and OS run drivers, or is this more an umbrella term you have used fo differentiate that which is on the SD card, from the physical hardware? Ie, would you also say that the kernel is a part of the software that is the issue? This is important for a reliably isolating the problem. I thought I was getting close, but this puts me a step backwards.
If it is indeed the software (which I am defining as Debian + the Launcher, and NOT the Kernel/DTB) I would love to know exactly what your findings are, and what steps you have taken fo potentially resolve it. In particular, whether or not you have tried using either the underclocked (which is actually stock), or overclocked settings.
Saying it is ādefinitelyā the software is an extremely decisive word to use, and one that can easily turn people off of trying the image if that is what they see. It will always be those who have problems who speak out the most; with those who donāt just going about their lives. Itās just unfortunate that only now, three releases into using the aforementioned kernels that we are getting an influx of reports of problems. These are the same kernels that have been in use since around June.
As mentioned above, the governed profile dynamically changes the clockspeed of the Gameshell, which seems to affect users who a) leave their gameshells on for extended periods idle, and b) those who use wifi for extended periods. I donāt actually use my gameshell this way; instead preferring to use the efficient suspend mode when I need to take a call, feed the pets, change trains etc. I never thought to test leaving it idle to see what happens.
Hmmm. The battery definitely seems like itās on its way out. It would be worthwhile to get a new one anyway. Just make sure you donāt get one rated over 1500mAh - if itās too good to be true, itās probably dangerous to use.
I doubt itās a cause, and heck, I donāt know if it would actually change anything, but at least in my field of work (music), people have been known to use an inline ferrite ring to reduce any buzzing/interference from a power source to audio equipment. Again, I doubt it would help, but perhaps give it a try. You can probably pull one off of an old mini USB digital camera cable. They normally have one on them.
Please do, and report your findings. While youāre at it, also attempt to replace the entire contents of the ābootā partition of the DEOT image with the contents of the stock 0.5 image. You should be able to see it as the drive that comes up when mounted on your computer.
I seriously doubt that it is a software related issue, and instead to do with the kernel. In fact, I believe it was in the 0.5 image that there was actually a test ā5.4.6ā that in the end was rejected in testing, no doubt due to similar problems to what people are experiencing. ā5.3.6ā became the standard kernel that initially brought us Lima support. I believe the kernel was made by @shell. See here:
@guu - do you have any memory of the there possibly being any problems with the 5.4.6 kernel that made it more viable to use the 5.3.6 kernel?
Either way, if the stock OS doesnāt produce any of the screen problems, donāt immediately dismiss it as being down to this custom image. It would be great to further development together if we properly narrowed down the root of the problems.
Currently I have got three CPI boards that I thoroughly test my OS on before publishing, and two sets of screens/arduinos/chassis etc. I would LOVE to get my hands on a nonfunctional board with the flashing screen problem. And even the exact card the image was flashed to. Iād be happy to do a 1 for 1 trade, although goodness knows how long that would take in the mail in this current climate.
It does mean a lot that so many people have been trying the image out, and testing it for and problems. I am extremely sorry for all the problems, and wish I could replicate them myself. Thanks for all being in essence, the testers. I would like to say that this image is stable and ready to be wrapped up, but that seems to only be the case for some people.
On a complete side note, if needed I can provide a video of my gameshell running using the 5.7 kernel, and not exhibiting any of the screen problems; just in case anyone thinks Iām telling porkie pies. Iāve posted videos in the past, and they have all been glitch free. Just let me know, and I upload a boot sequence, display of the about screen to indicate the kernel, and running a game of choice. But realistically I donāt thinks itās necessary.
I mean that I took official OS and added switchers for kernels and kernels themselfs from this custom OS to test them out (how well they work) and I got theese screen glitches. This was a while back ago so I donāt remember which kernels and with or without overclock. When I switched back to stock kernel they gone (glitches). That is all I gotā¦
Right. So a while back could be any of the kernels that were in testing up to this point. If you can be specific, that would be fantastic, seeing as the kernel in question people are having problems with is 5.7. If it was a while back, ie before June, it was probably a different kernel.
Sounds like when you meant a problem with the software, you were referring to the kernel, since you said you tested the kernel on a stock 0.5 image and you got the same results. I just want to confirm this is the case.
Also you mentioned that when you switched to the stock kernel, all the glitches were gone. Was this in the custom OS, using the stock kernel selection? Or was this in the stock OS, after returning to the original kernel? How did you go about changing the kernels?
This puts my fears to rest re: the problem being on the OS side of things, since that is FAR harder to debug.
Again, I am thinking that potentially, with higher frequencies, precision of build quality may come into play, or even the speed at which the SD card is accessed etc. This would come down to hardware.
I just thought Iād lay this to rest before definitively saying itās ādefinitelyā the software.
Right! I think this could solve some peopleās problems.
I will give this a go during the week when I have some free time. But meantime, other people should also give this a shot. It shouldnāt be hard.
This was something mention by @r043v to me in the past when other people were experiencing similar problems; more than a year ago. I just figured that since a) I wasnāt experiencing the problems and b) prior to now, I hadnāt received any reports of problems, that it wasnāt necessary. SURPRISE!
Iām not going to release an updated image, until Iāve had this thoroughly tested.
Could I kindly ask if anyone who is experiencing the problems would like to test out some custom kernels, and report back on whether or not there are any issues? Preferably someone who can follow potentially difficult instructions, and put up with my extremely verbose nature. 
1 Like
as arch kernel already ship this patch they also can try the arch linux image, if screen not flicker it will mean thatās the problem
1 Like
Sync 200903
Manual download from GitHub
Or git clone
git clone https://github.com/hi80482/launcher_deot.git ~/launcher
sudo reboot
Or Update Launcher from Setting page.
1 Like
I run the RetroArch update script in command line, it works.
My GameShell CPU is R16J,
Set all clock speed(1008, 1200, 1400) + new kernel (> 5.3.6) = screen flicker,
It randomly after booting, about 5% to 10%, not often.
Reboot or return to kernel 5.3.6, will fix it.
No rules, I donāt know how to replicate the problemā¦
2 Likes
I reflashed the microSD card and set it to Stock Kernel. It works now!
2 Likes
I actually managed to get one of my CPI boards to do what yours has on the bottom footbar. A light line going through the buttons. Pretty much in the same place.
Using the 5.7 kernel, I just did a reboot; without changing the kernel and then the line vanished.
This was a CPI board that would show the line maybe 50% of the time. Not great, but much better than some other peopleās result. So far, doing a simple reboot has fixed it every time, although I havenāt done much more besides this, ie I havenāt done any extensive playing after the reboot to see if the problem comes back.
Before people immediately assume that changing to the stock 5.3.6 kernel fixes the problem, try a) a simple reboot while still on 5.7, and b) doing the suggestion suggested a few posts up. I will be looking into it on the weekend when I have some time.
1 Like
I did do a reboot to try and see if that would help, and it did, but I then let it sit for a few minutes and it progressively got much worse over time. To being unusable. With either the gpu driver or software rendering, it was the same.
1 Like
Flashed stock OS to a spare SD, and zero issues. Very doubtful itās something hardware related (ie dying battery/poor cable connections).
So, other questions. Is there a way to remove all the custom Kernel stuff and set to stock, while maintaining all the data (ie games, standalone emulators etc.) in the SD without reflashing??
Moreso, if I select the stock kernel, should I still be seeing the DEOT splash screen on bootup??
ANOTHER EDIT: Strangely all my glitching has disappeared after trying my other memory card with stock OS on it. Canāt remember what kernel and clockspeed I had set on the custom OS card before changing it. Disregard. Glitchy is back.
1 Like
could you try flashing arch image ?
1 Like
Iāll give it a try today if I get the chance.
EDIT: Tried this (is this what you meant?) and still getting the glitchy screen, although itās not too bad as it comes and goes
1 Like
no, i meaning the arch linux port > [OS] Arch Linux
3 Likes
Iāll give it a shit shot when I get the chance
1 Like
as you own one of the few motherboard who raise the flicker problem if you could have a look it could help us a lot to detect where is the trouble
after you have flash os & setup your wifi profile, reboot and call the āupdateā command to install last launcher & kernel, finally reboot again to use them
1 Like
So far, zero glitchiness on Arch
3 Likes