Closed TomWhitwell closed 1 year ago
This is caused by https://github.com/waveshare/e-Paper/commit/99f6a13540da0d4ad5a1291343068e0220f8b219. It's supposed to refresh faster.
What is a proper "fix" on the part of either SlowMovie or omni-epd for this? It seems to only affect a handful of displays (the 7.5 for sure). We could tag a specific Waveshare version but that might affect potential fixes for other issues across other devices in that same repo. Is this more of an FYI and we put some disclaimers up for people in various places in the README or install scripts?
I don't know, I'm not sure of the best approach.
It feels sad to me because all the work you've done to get a simple beginner-friendly one-line install now fails for the 'original' screen in the article and the default.
Do you think that update of the 7.5 inch monochrome screen driver is just a mistake on their end - will it break anything trying to render complex images on the screen? I don't really understand the system well enough. Should I report it as a bug? Should they have implemented a new fast method that doesn't break the existing method?
Options might be:
Been thinking about this for a while - how does this sound for a tentative fix?
Thoughts?
Hi Rob, hesitating on this because my OG VSMP isn't working - just did a completely fresh install of Raspberry OS, checked the mode switches on the hat, ran your fix above and I'm getting super noisy & streaky images, similarly with the waveshare test script - it's like it loads the image correctly, then as it refreshes, a lot of black pixels turn white.
I think your suggestion sounds ideal, but not currently working for me unfortunately.
That's really bizarre given that the old version from above has fixed it before. I'm hesitant to mess up my own setup but I'll flash a new SD and do a clean install as well to see if I get the same result.
I know - it feels more like a hardware problem - I reverted right back to my original code and it behaved the same. I think had it set in the wrong switch position for a while, wonder if that did some damage. Maybe 25,000 hours of use is excessive? BUT still, it's clearly receiving data and refreshing. So maybe not hardware at all!
I did a clean install of the most current branch of the waveshare python libraries. Noticed streaking on every image I tried to load. I uninstalled this and did an install using commit b36cfab0ea336673982640ea21969e5a54714448
from above. Streaking stopped and things went back to normal.
Your issue may very well be hardware related :(
I've started a PR to add a disclaimer to the README and allow for the option to rollback the driver via the install script. Hopefully this should catch most use cases.
I've just purchased and attached a 7.5 V2 Waveshare without any problems.
Used this driver waveshare_epd.epd7in5_V2
if that helps any.
Wx
Going to close this out since @missionfloyd has fixed this in the Waveshare lib.
Notes on the issue highlighted and worked around in #134
Between June 2021 and October 2022 there were two significant updates to epd7in5_V2.py in the Waveshare repo.
The system for writing data over SPI was changed -
send_data2
usesspi_writebyte2
rather thanspi_writebyte
This was discussed here back in #18getBuffer
is significantly changed - I don't understand the changes thereThe impact on SlowMovie is that the screen is very streaky (see images in #134 ) if SlowMovie is installed or updated.
The workaround is explained here - by @robweber
I don't know if this impacts any other screens - there were a couple of specific bugfixes on epd7in5_V2.py
I don't know which change (or something different) is causing the streaking.