Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Further 4in2 improvements #64

Merged
merged 6 commits into from
Feb 20, 2021
Merged

Further 4in2 improvements #64

merged 6 commits into from
Feb 20, 2021

Conversation

caemor
Copy link
Owner

@caemor caemor commented Jan 27, 2021

@David-OConnor & @mgottschlag:
Is there anything left to do or missing for this from the other 2 issues to round this up?
I copied most of the relevant issues to below:


For #48: I also applied this to the QuickRefresh Trait since its never changed anywhere it should be okay to just apply it once at the beginning like mgottschlag said.


For the new QuickRefresh Trait

  • Is the documentation understandable enough for new users so they unterstand when and how to use it? And how to implement it for others displays?

From:

I think the doc comment should

  • state when the user needs to send the old data
  • explain why this is necessary
  • maybe give an example?

I think this whole old status/new status stuff is fairly confusing. I can write a patch for that this weekend if you want.

Originally posted by @mgottschlag in #54 (comment)


Other things from #47:

I have experimented with the 4.2 inch e-ink display from waveshare, and the last days I have tried to make quick refresh work. I have observed a number of deficiencies in this library, some of which I do not know how to fix:

* [ ]  Newer 4.2" B/W displays seem to require different LUTs for quick refresh.
  As indicated by a comment below [Ben Krasnow's blog post on quick refresh on this display](https://benkrasnow.blogspot.com/2017/10/fast-partial-refresh-on-42-e-paper.html), there are two versions of the display. I copied the LUTs from the example code for the greyscale Good Display display (does that mean that my B/W display properly supports greyscale? Yay!) and those result in proper black/white pixels, whereas the LUTs in this library currently only result in grey pixels.
  Link to the example code: http://www.e-paper-display.com/download_detail/downloadsId=1022.html
  My commit (the old LUTs should probably be accessible though - preferrably not behind a feature gate, but selectable at runtime): [mgottschlag@a24bec5](https://github.com/mgottschlag/epd-waveshare/commit/a24bec5be720c89cedda513a139bc983b0c5e1d0)

* [ ]  I am unsure what the point of the "background color" provided by this library is - the documentation is lacking and I think usage the background color as-is is wrong and unusable.
  My understanding of the background (or "old" frame as called by the documentation is that it allows to choose different LUTs based on what the previous image was. Note that the data is actually required for quick refresh using the LUTs in the example code above, as those completely skip pixels that do not change color!
  Also, using the wrong background data might cause burn-in issues. According to the internet (I think Ben Krasnows youtube video explained something like this), the applied voltage needs to be on average 0 to prevent charging the display, which causes burn-in. I don't understand the format of the LUTs, but if they are not completely balanced (and inofficial quick refresh LUTs likely are not!), then using the same LUT over and over again causes the display to be charged (whereas only applying voltages during black/white and white/black transitions might cause the effects to cancel each other out and also greatly reduces the number of pixel changes).
  At least, the library requires updates to the documentation.

* [ ]  The library does not provide a method to upload the "old" ("background") data.
  The official quick refresh LUTs for this display depend on having the old data.
  My take on this issue: [mgottschlag@dbd065a](https://github.com/mgottschlag/epd-waveshare/commit/dbd065a71595b62147b5a4af8846f1ce1af6e191)

Closes #54 and #47

@caemor
Copy link
Owner Author

caemor commented Feb 20, 2021

I am gonna merge this for now. We can update anything missing later anyways.

@caemor caemor merged commit 181010f into main Feb 20, 2021
@caemor caemor deleted the Further4in2Improvements branch April 18, 2021 16:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant