A04 screen display vertical offset

Research still counts! It’s been great to see the progress you all have been making on Manjaro. I’ve never actually used that distribution myself, but I’ve enjoyed quietly following along. And it’s given me more hope for the Devterm platform, as if it’s officially supported by Manjaro that will be another stable and maintained OS option. (And while I’m comfortable with Debian/Ubuntu, I’m always keen to learn new stuff.)

1 Like

I’m playing with xrandr and at least you seem to be able to get a 475x1280 display with
xrandr --newmode test 50.00 475 560 580 620 1280 1330 1332 1360 -hsync -vsync
Warning: this may be risky; use at your own risk. I tried some other values and it made the display blank until restarted.
The top 5 pixels are cut off; the bottom extra pixels are still there.
The modeline reported in Xorg.log is
50.0 480 560 580 620 1280 1330 1340 1360 -hsync -vsync

1 Like

Well I would love to help more, but until we have more documentation about the LCD panel itself it’s going to be hard to know what all of these black magic register pokery is doing.

I suspect that looking at some value in decimal instead of hex may give a hint on some of them, but from my own experience working with video signal without proper documentation can be really really tricky. You can guess/find some value, try to change them and get results that are completely out of what you would expect them to do (or do nothing visible, also happened to me a lot of time)

I was not answering what I was saying as in “I don’t care” but more in “without doc, I fear this is just black magic”…

2 Likes

I asked Hal from ClockworkPi about it in relation to some other stuff, and he was able to get the datasheet posted: DevTerm/ICNL9707_Datasheet.pdf at main · clockworkpi/DevTerm · GitHub

very similar to the ICNL9706 datasheet I found earlier doing the Manjaro work and suspected might be the IC. the ICNL9707 one might better explain some of the init sequence stuff I couldn’t find in the ICNL9706 one, but haven’t had a chance to read it yet

Edit: the more I stare at the init sequence though…. the more it seems like it is actually the ICNL9706 :confused: unless there’s missing commands from ICNL9707 datasheet that are present in the ICNL9706 datasheet

3 Likes

@m4xm4n , I’m happy to provide code review help, but I don’t think I can offer any additional aid in actually adjusting the driver; this isn’t quite my field.

Do make sure you’re using the Armbian kernel (or whatever you’re using for Manjaro) plus the 5.x patches from the DevTerm repo rather than the 4.19 one that was mentioned earlier.

You can apply an xrandr --transform to offset the screen which seems to solve this:

# the -1 value below is the y-offset
xrandr --output None-1 --transform 1,0,0,0,1,-1,0,0,1
2 Likes

This works for me, thank you! Will this persist after a reboot?

No, xrandr only affects the current running session. There may be some way to transform that into an /etc/X11/xorg.conf.d snippet, or you can put it in a script in /etc/X11/Xsession.d/

Nice! -4 shifts best for me.

This makes it apply upon boot.

I appreciate the assistance! Do you know if using cron and the @reboot argument will work?

No. It needs to run after Xorg has started.

Beautiful, thank you!

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:

4 Likes