First, I don't want to make it sound like a bug in the library it self, but rather a case of mysterious Chinese display specification.
I have had this weird bug were using GxEPD2 for the 880x528 HD version of the bw/r 7.5 inch display.
The symptom are that the red color is combined with black, especially when using only a small part of red on the entire picture.
The demo code from waveshare worked just fine.
After some digging, I found a discrepancy in the gate mux register 0x01.
In GxEPD2_750c_Z90.cpp byte 1 and 2 is set to 0x20F = 527, spot on according to Good display demo code and the comment for 527.
Line 385 to 387 in GxEPD2_750c_Z90.cpp
_writeCommand(0x01); // Set MUX as 527
_writeData(0x0F);
_writeData(0x02);
However, in the waveshare demo, the register is set to 0x2AF = 687, even though their comment states 527.
EPD_SendCommand(0x01); // Set MUX as 527
EPD_SendData(0xAF);
EPD_SendData(0x02);
Changing the 0x1 command to 2af in GxEPD2_750c_Z90.cpp restore proper operation of red color on the display.
I tried playing around some with the value and incrementing a small value above 527 did nothing, still combined b/r.
The display driver datasheet states that the reg goes up to 680 so setting 687 is above the max, changing to 680, 0x2A7 naturally makes no difference and the red is still preserved.
I can’t find a proper datasheet that states the gate driver register values(Or any for that matter) , only example codes so it is hard to figure out what is going on for this display.
It would be very interesting to see if someone could try to replicate this issue.
Given that the display is discontinued on the waveshare site I am not sure if one should spend too much time on it.
It should be noted that I have experienced that the display starts working correctly with GxEPD2 lib after being set properly by the waveshare code until next power cycle, something to keep in mind if trying to replicate. Changing the 0x01 value in GxEPD2 gives immediate results.
That in it self is odd, but lack of documentations makes it hard to figure out, I have a feeling it might be a different register accountable for all of this, but no way to figure it out without going for a deep dive.
Waveshare demo code used: https://files.waveshare.com/upload/5/50/E-Paper_ESP32_Driver_Board_Code.7z
Relevant section from datasheet for the display driver SSD1677:
