odd quirks with GDEY029T71H

[moosepr]

Hi there! I came across your lib while looking for e-ink libraries on my project (its a keyboard/esp32s3/2.9" eink screen mash up called CL-32) and so far its been great!!

I have been having a few issues with the higher resolution GDEY029T71H screen (yours is the only lib that supports it so far)

Firstly it seems that the top few rows of pixels are being ignored. Im guessing this is maybe a slightly newer variant of the screen and the starting offset is different?
Secondly fast updates seem to get mangled. it doesnt seem to clear the old data before adding the new, so things quickly become weird when overtyping text

as a side note, there is barely any flashing during full refreshes. While that is way more attractive, is this a sign of some update weirdness or just a better quality screen?

Thanks in advance and thanks for making a great library :)

[ZinggJM]

Hi @moosepr

I would like to know from where you bought your display, and when.
If it is from Good Display, then I will ask them if anything has changed.

If fast full refresh doesn't work correctly, then you can disable it, setting useFastFullUpdate to false in line 31 in the header file.

[moosepr]

Both screens were purchased directly from Good Display in July this year. I have done some little videos to demonstrate

The low resolution screen (GDEY029T94) works as expected, the text gets replaced with the new text on fast/partial update
https://youtu.be/wshjd85ObX4

The high resolution screen (GDEY029T71H) shows a few lines of un-initialized buffer at the top of the screen, and everything is shifted down. When replacing text, both versions seem to remain, but if you are putting text onto an empty screen it works fine
https://youtu.be/P8qvQq7L7Ro

Both versions are running the same code other than the screen setup line and the bitmaps for the relevant resolution

[moosepr]

I have tested with the Good Display demo code and that works 100% as expected.
I tested the GxEPD2_Example and while the line of 'snow' is visible on the first init of the screen the same as my code does, the rest of the example seems to work fine, all the images load all the way to the edge of the screen, and any fast updates all work fine too. I will have a look through how you are doing the demo stuff, see how different it is to mine

[ZinggJM]

Do you use processor sleep with partial update after wake-up?
There had been an issue with an earlier version and displays with SSD controllers.
I didn't test for this issue with this display, it is a test from a users code.
Maybe I copied code from a driver class that didn't need this fix.
But this doesn't look like, from a quick code comparison.

If you post your code, or a reduced one that shows the effect, then I can guess more quickly.

[moosepr]

I have knocked up a quick test sketch.
Running it as partial updates doesnt let me draw the rectangle all the way at the top of the screen, the first text print is in a different place to all the others after
Running it as a full update, the first update is offset, then every update after is where it should be
test.zip

[ZinggJM]

Thank you! I see the issue, but I don't yet understand where it comes from and how to fix it. It is related to:

    static const uint16_t SOURCE_SHIFT = 8; // S8..S175 connected to TFT sources

[moosepr]

i did start comparing init sequences and quickly got lost!!

glad the demo helped

[ZinggJM]

The reason is found. Fixed in for now in branch work_in_progress.
File: https://github.com/ZinggJM/GxEPD2/blob/work_in_progress/src/gdey/GxEPD2_290_GDEY029T71H.cpp

  // NEEDED before first _setPartialRamArea
  // reason: OTP set for 168x384, but TFT shifted: S8..S175 connected to TFT sources
  _writeCommand(0x21); // Display Update Controll
  _writeData(0x00);    // RED normal
  _writeData(0x00);    // 200x384
  _setPartialRamArea(0, 0, WIDTH, HEIGHT);

[moosepr]

just replaced this file in my local copy and it works perfectly!!!

Thankyou for the super speedy fix, and thanks again for the awesome driver :)