At first sight, the very top part of the screen is a bit weird to me, but I don’t know why.
(maybe due to the icon of chromium is not full circle 
)
After some fiddling on the first day with my A04 devterm, I noticed that the very top of the screen is actually flipped to the very bottom of the display. (may be just 1/2 pixel lines)
Carefully, you can see in the big red box, the active window blue shadow shows on the bottom, even the mouse cursor tip…
Gathered links from replies:
i also have this issue on a06
Yeah, I have exactly the same issue. I thought that I got a slightly bad screen… Good (?) to know that I’m not alone.
There’s another thread on this, which @Godzil responded to. The response was basically “good luck” though, since apparently no one knows how the screen is supposed to work, it’s not documented, and it seems to be a driver issue.
More information is here, along with source:
I’m kinda hoping someone working on the Manjaro port ends up fixing this. Sounds like they’ve already fixed the issue with DevTerm not properly waking up from sleep, and they seem to be making amazing progress in general. I’m not sure if they’re aware of the issue though. Perhaps I should ping them here (hope you don’t mind!): @spikerguy @m4xm4n @veritazz
As a side note there’s also a less driver-dependent issue involving the screen – its weird size. In some cases, windows get cut off and are unusable since they weren’t created with a max 480 pixel height in mind. One (easy) way around this is to scale the screen to 1.5x in the display settings, but other options would certainly be welcome.
I’m kinda hoping someone working on the Manjaro port ends up fixing this.
if I see it myself, I’ll take a look. But can’t say I’ve seen it yet (but I also wear glasses, might be too small for me to notice. tbh I can’t really even tell from the screenshot)
Sounds like they’ve already fixed the issue with DevTerm not properly waking up from sleep
clarification: we didn’t do any of the actual fixing on that, I just happened to find a patchset from someone else that submitted patches to the Rockchip SoC kernel subtree to fix the Rockchip MIPI DSI driver suspend/resume issues. Just happy timing/coincidence 
after lots of searching
The panel drivers are Code/patch/armbian_build_a06/patch/kernel-004-panel.patch and Code/patch/armbian_build_a04/userpatches/kernel/sunxi-current/kernel_005_panel.patch in the DevTerm repo for the A06 and A04 respectively. Hopefully there isn’t much difference between them…I haven’t taken a close look. The A06 and A04 are very different SoCs but the panel is the same in both models.
The code doesn’t look too promising at first glance - lots of magic numbers in init sequences with not a lot in the way of #defines for command IDs or anything, and I don’t have a lot of experience with hacking on graphics drivers so I can’t tell if something’s funny with the mode parameters in default_mode or anything.
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.)
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
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”…
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
@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
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!
