Screen scrambled on Clip Zip with RB 3.15

[Bilgus]

could you try V2 again it is an optimal solution that I can put in main with no issues to any other players

[sansalex]

could you try V2 again it is an optimal solution that I can put in main with no issues to any other players

I'm afraid: with the new clean device, the build V2 still has the issues. It looks like V1 is the only one resolving, do you want me to check V3 again?

[Bilgus]

Ok here is another try that I won't feel too bad about pushing to main

Honestly I haven't heard of another clipzip user having this issue even among the 3 I personally have access to

http://www.mediafire.com/file/sdi2bb6ru64olgi/ClipZip_Corrupted_displayV5_2-27-20_rockbox-full.zip

[sansalex]

Ok here is another try that I won't feel too bad about pushing to main

Yep, V5 is working fine!
May I ask the difference between V1/3 and V5? And why turning off/on is a dangerous solution? This is just for my curiosity.
Thanks, man 

[Bilgus]

None of them are dangerous solutions just non optimal
V1 I turned the screen on and off when the backlight started up

v2 I noted the lcd code is using a static bool variable that is only implicitly initialized
     basically the compiler is expected to set it to false but since the bootloader already
     used this variable it is possible it is already initialized to true

v3 turn the screen off and on again right before rockbox loads the main menu

v5 the lcd_enable command blocks if already set to the same state so if its enabled it won't re-enable it
     There are two different displays for the clip zip and I'm guessing you have the rarer undocumented one
      With no device to test its really hard to write code for it so the best I can do is write code that doesn't affect other devices negatively
      AND hopefully fixes your device

Could you try one last build I noticed there has been a change in the code between 3.13 and 3.14 on the backlight initialization
again in the name of power savings could you try this reversion of http://gerrit.rockbox.org/r/#/c/989/
https://www.mediafire.com/file/4hj1ao2lm1nzwq8/ClipZip_Corrupted_displayV7_2-28-20_rockbox-full.zip

Here is the patch if you are interested in seeing it
http://gerrit.rockbox.org/r/#/c/2303/

[sansalex]

     There are two different displays for the clip zip and I'm guessing you have the rarer undocumented one

That's what I was thinking: my hardware could be slightly different.
I still have the original box and it says product number is SDMX22-004G-E46R, I don't know if this information is useful.

      With no device to test its really hard to write code for it so the best I can do is write code that doesn't affect other devices negatively
      AND hopefully fixes your device

Crystal clear.

      Could you try one last build I noticed there has been a change in the code between 3.13 and 3.14 on the backlight initialization
      again in the name of power savings could you try this reversion of http://gerrit.rockbox.org/r/#/c/989/

I tested V6 and it works. However I see you now re-edited by providing a V7, I will try this.

EDIT: V7 working too.

[Bilgus]

awesome I've already tested it on my device so i'll push it in a few days and it will be in all dev versions / releases from then on

Thanks for testing

[Bilgus]

The box for mine says SDMX22-004G-C57B but it means nothing to me lol I'm sure sandisk has (had) a nice list of what the last 4 characters mean

[sansalex]

awesome I've already tested it on my device so i'll push it in a few days and it will be in all dev versions / releases from then on

Thanks for testing

Great! Thank you so much! 

The box for mine says SDMX22-004G-C57B but it means nothing to me lol I'm sure sandisk has (had) a nice list of what the last 4 characters mean

They absolutely know the meaning and also the hardware nuances associated with those characters, but they'll never tell us the details hehe