Display not supporting partial updates?

[ondras]

Hi,

I built the whole keypad, but I am starting to think that my e-ink display is not supporting partial updates. I am opening this issue to organize my thoughts and seek advice.

I have a second revision of the display, so I adjusted the wiring, constants (settings.h) and constructor (GxEPD2_290_T94) according to https://www.reddit.com/r/arduino/comments/l4wxxf/the_hardware_is_assembled_and_passed_all_tests/gqovq1j. I did this both in the hardware-test sketch as well as the main inkkeys sketch.

I tried:

1) the hardware test sketch. This one works flawlessly, shows circle patterns. I am not sure whether this uses partial updates or not.

2) the regular inkkeys sketch. The serial protocol works. I launched the python script and loaded the ModeGimp() mode. The display remained blank/white. Keys are working according to the Gimp mode.

3) I then connected to the keypad via serial and issues the R f command. Magically, everything (icons) appeared on screen.

To further debug the issue, I restarted the keypad, did nothing Python-related, opened the serial terminal and issued:

D 50 50 8 2 <enter>
AA <enter>
R f <enter>

This worked: two small rows with several black bits appeared. However, when I did the same with partial refresh, nothing appeared:

D 50 50 8 2 <enter>
AA <enter>
R p <enter>

Finally, once I issued R f, everything that has been previously sent (and failed to partially update) appeared.

This is what I bought: https://www.aliexpress.com/item/32811510579.html

Do you think this can be solved software-wise? Or shall I contact the seller? I would be happy for any comments/suggestions.

[ondras]

Update: just found out that there is another class, GxEPD2_290_T94_V2, that might work better with my Display. Will try that and report.

[ondras]

The _V2 class fixes the issue! Closing this with a PR to mention these new classes in the Arduino source code: https://github.com/Staacks/inkkeys/pull/17

[ondras]

It is still problematic, unfortunately.

This happens when I press the jog wheel in the Gimp mode:

Note that the "tool size" label has been overwritten by the new (probably "Tool opacity") text only partially. This is definitely because of the partial refresh; issuing a R f fixes the screen.

Looks like that during partial update, 1) black works (previously white pixels are set to black), 2) white does not (previously black pixels remain black)

Moreover, based on my experience, the whole flow regarding partial updates and double data streaming (as described in https://there.oughta.be/a/macro-keyboard#the-arduino-code) is not really working as expected. After a fresh reboot, I tried this:

D 0 0 8 8 <enter>
@@@@@@@@ <enter>
R p <enter>

This performed a correct partial update. However, I then sent another R p (without re-sending the image data) and nothing happened. I sent another R f, the screen blinked and the pattern in the top left corner persisted. In other words, I am unable to reproduce the case "missing partial data in the backbuffer".

[Staacks]

Unfortunately, I cannot try any of this as I have a rev 1 display (very unfortunate as it seems that I received older stock while most other people have the newer version and therefore some compatibility issues). But your description indeed sounds like your version of the display updates the backbuffer on its own. Still, I think that resending the data should only result in unnecessary communication overhead, but I would not expect visible consequences.

Still, if you want to try disabling the second data submission in the Python code, you just need to comment self.resendImageData() in line 173 of "device.py". You can also try commenting the next line, but that should only turn off the power to the display ("R o") - but who knows what that does on the new revision.

[ondras]

Still, if you want to try disabling the second data submission in the Python code, you just need to comment self.resendImageData() in line 173 of "device.py".

I think that the re-sending is not doing anything harmful in my case. I was doing some experiments using the serial protocol only, namely:

D 0 0 8 8
<white/black data>
R f

and then:

D 0 0 8 8
<black/white data>
R p

...and I ended with a black square. In other words, partial update only renders black pixels. I am unable to switch a black pixel to white via a partial update.

(Actually: those black pixels that should become white do happen to change a bit, to a less-dark shade of gray. But they still remain much more "black" than "white". This can be seen in the photo posted above as well: the original text is present, but in a tiny bit lighter shade of gray when compared to the overwriting text.)

[Staacks]

Actually: those black pixels that should become white do happen to change a bit, to a less-dark shade of gray. But they still remain much more "black" than "white". This can be seen in the photo posted above as well: the original text is present, but in a tiny bit lighter shade of gray when compared to the overwriting text.

That does not sound like a logic problem but an electronic one...? Maybe you should test the display with one of Waveshare's demos.

[ondras]

That does not sound like a logic problem but an electronic one...? Maybe you should test the display with one of Waveshare's demos.

Perhaps. Honestly, I am kind of "over the limit" for this project, spending waaay more time and energy on it than I initially thought. My use case is somewhat reduced (only one "mode"), so I am going to stick with one (initial) full display update and call it a day.

[Staacks]

Understandable. I will keep this issue open for a while. Maybe there will be feedback by users with the same display revision. But so far others only had to use the other class and switch two connectors as described in the readme (https://github.com/Staacks/inkkeys#display-revision-2).