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 
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.