A04 screen display vertical offset

This was discussed on another thread and it sounded like the xrandr method was a.workaround and not an actual fix since either either can be used to shift the missing pixels to the bottom instead of top of screen, or it can be used to stretch the screen as a “fix” which ends up distorting the image. See the discussion below:

Sweet. that transform worked for me too. I use i3, so I just exec the xrandr transform from the i3 config.

I tried to interpret it today and the commands written to the driver is definitely different from what’s on 9707 datasheet!

If interpreting with 9706 I got this:

// VBP          0Ch    Vertical back porch          12HS                                                                                                
// VFP          16h    Vertical front porch         22HS
// VSW          04h    Vertical low pulse width     4HS
// HBP          0Ch    Horizontal back porch        Disable
// HFP          10h    Horizontal front porch       16 Clock
// HSW          04h    Horizontal low pulse width   Disable
dcs_write_seq(0xC1,0x0C,0x16,0x04,0x0C,0x10,0x04); // TCON (Set VBP, VFP, VSW, HBP, HFP, HSW)
// NL_FIX        0h
// NL          141h    Resolution, step 4hs         1284hs (???)
// RSO           1h    Resolution (HS)              600hs
dcs_write_seq(0xC2,0x11,0x41); // TCON2 (Set resolution)
// I2O_BLKF_S    2h    SPIN to SPOUT blanking       2 Frames
// BLK_KP        0h    Keep blanking in OFF         Stop
// O2I_BLKF_S    2h    SPOUT to SPIN blanking       2 Frames
// REV_EOR       0h    Reverse xor                  Normal
// B4_EOR        0h    MADTCL D4
// B3_EOR        1h    MADTCL D3
// B2_EOR        1h    MADTCL D2               
dcs_write_seq(0xC3,0x22,0x31,0x04); // TCON3 (Set frame blanking) 

Doesn’t feel quite right, but I don’t know about driving panels.
That 1284HS… It’s outside valid range in datasheet.
Nevertheless I’ll put together what I find here.

Tried 0x39, 0x40, no difference.

A possible cause is that the TCON parameters do not match with drm mode settings, so drm buffer are written “too late” ending up with blank area.

Tried to match HSW, HBP, HFP to drm setting, no difference.
Increasing these values (and also in drm) results in frame skipping. (This is expected, same effect as X mode setting)

Tried to modify B2_EOR from 1 to 0. Expected display to go upside down, but nothing happened.

Did some of the unknown commands override all the settings or reset them??

Thanks for digging this up, can you give me a hand in regards to reinitializing the display driver without recompilling whole kernel? I would love to debug this.

@gougou I tried to hot reload the module and it does not work – screen cannot be brought back on and it fails to reboot cleanly.

The best way is to first prepare the kernel tree (by either building it or some manual steps), and then make SUBDIRS=drivers/gpu/drm/panel modules

Then, gzip panel-cwd686.ko and copy it to /usr/lib/modules/... and prepare your initramfs.

Update: A partial fix is now available.

Patch the display panel driver:

Then use a xrandr command to crop it back to 1280x480:

xrandr --output DSI-1 --mode 485x1280 --fb 1280x480 --transform 1,0,0,0,1,-5,0,0,1 

This hack clearly shows that the display scans from bottom-to-top in our view, or left-to-right in the panel’s native orientation, in contrast to what is specified in the known commands in the driver…

That’s why the newly extended height accommodated the top lines instead of introducing out-of-panel pixels :slight_smile:

6 Likes

I know this is old, but do have any idea what might be involved in porting that fix to the raspberry pi releases? I’m going to dig in later, but I’m having the same issue there and would love a proper solution.