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