we have developed a custom system based on a TX2 Jetson and some weeks ago switched to Jetpack 4.3.
Our display panel has an ILI9806E Controller, a resolution of 480x800 and runs mostly well connected to head0.
The remaining issue with the display is, that there is some wraparound of 8 rows visible.
9th : top display row
…many incrementing rows…
4th row : bottom of display
Each horizontal line displays fine and adjusting the display timings does not seem to have a direct effect on the issue. My colleagues had the same issue with older Jetpack versions.
I also tried direct access of the fb0 device without X and found the same behavior.
Do You have any idea on what I should examine to get a correctly working display panel?
What is the interface for your display panel?
Could you take a photo to describe this behavior?
sure I can take a picture:
The display is a DSI connected MIPI display.
Attached is also an excerpt from the currently running device-treeexcerpt.dts.txt (6.7 KB)
What would happen if you run full screen render application?
Will those rows still get cut there?
Like tuxracer or mpv with fullscreen video? Yes, they are still cut. I also shut down X, unblanked the framebuffer in ‘/sys/bus/platform/drivers/host1x/13e10000.host1x/15200000.nvdisplay/graphics/fb0/blank’ and used mpv to display fullscreen on fb0, but still the pixel rows were wrapped.
Sorry for late reply.
Could you check with gstreamer pipeline ended with nvoverlaysink?
If even nvoverlaysink has this behavior, it means this issue is from the kernel side.
I managed to show a testvideo like this:
gst-launch-1.0 filesrc location=./TestVid480x800.webm ! matroskademux ! vp8dec ! videoconvert ! nvoverlaysink
And still the same shift of pixelrows is visible. Do you know of some technique to narrow down the software layer that causes this behaviour?
Is there any other resolution to choose here? Are you sure current display mode can work fine on your panel?
Its the native resolution of the panel and as far as I know the only resolution that can be used. We also have confirmed the display working with the init sequence fine with some STM32 with MIPI DSI in the past. I found the panel also being quite tolerant with the signal timings. My best guess is that there might be some offset in the memory address from where the pixels are read due to something about the window/head setup? The nvoverlaysink directly writes into the GPU memory right?
Perhaps I could somewhat configure a 480x400 „framebuffer“ and scale it up to the 480x800. If this works we would know for sure, that the whole DSI-head path is working correctly. Do you think that is feasible thing to do? And where would this scaling be done best? With the help of the VideoImageCompositor of the TX2?
The nvoverlaysink directly writes into the GPU memory right?
Perhaps I could somewhat configure a 480x400 „framebuffer“ and scale it up to the 480x800.
You can use nvvidconv in gstreamer pipeline to do the upscale.
Actually, I think this issue is from the display driver. You could check the pclk log in your dmesg and see if it really matches your desired pixel clock value.
Also, check the timing here.
sudo cat /sys/kernel/debug/tegradc.X/mode #X=0,1,2.
The ref clk in tegra may not 100% match your desire pixel clk and cause something missing.
I checked the timings:
clock-frequency = <30240000>;
hactive = <480>;
hfront-porch = <60>;
hback-porch = <30>;
hsync-len = <6>;
vactive = <800>;
vfront-porch = <54>;
vback-porch = <20>;
vsync-len = <1>;
nvidia,h-ref-to-sync = <1>;
nvidia,v-ref-to-sync = <1>;
and the kernel:
root@jetson:/sys/kernel/debug/tegradc.0# cat mode
The difference in the pclk is not critical both are well in the specification of the display. And if I change it, there is no visible difference. The display controller has a wide range where it should work. One thing where my integration differs to the panel-s-wuxga-8-0.dtsi is in the node
…/disp-default-out/ nvidia,out-parent-clk = “pll_d”;
If I put “pll_d_out0” there I get error messages and a boot loop.
The second thing I have no idea is the [h,v]-ref-to-sync node. I found the description in an older jetpack that it specifies the start position of V/HSYNC with respect to H reference point. But what should such a reference point be? Is the node even used by anything?
Sorry that I was thinking few rows are “disappeared” from the panel, but it turns out these lines are shown in the bottom of your panel. Didn’t notice that.
I am checking with some experts for this.
Will update to you later.
yeah… 4 of the 8 missing lines appear in the bottom. I am happy to try anything :)
Thanks a lot.
I also wonder how did you tell the line numbers that are disappeared are 8 and how do you notice 4 of them are in the bottom?
Do you use framebuffer interface to check specific patterns?
At first I saw the mouse cursor appear in the bottom when it moves out of the top. So I put up a 480x800 picture with easy countable patterns.
The shapes in the top and bottom help to identify the line number.
I measured for easy mesurement in Xorg, but verified the same effect with nvoverlaysink and /dev/fb0
/dev/fb0 is a bit strange though, since I always have to unblank it first. I should get an fbcon with bootlogo, but the screen stays black until X.
Does only cursor wrap around here? I mean why the dark read color does not appear in the bottom?
sorry for beeing unclear about that: this is only the test-pattern image file. The wrap around only occurs when beeing displayed on the panel. The whole display gets wrapped around, not only the cursor and if I render the testpicture in the panel 4 rows of the dark->red transition appear in the bottom of the display and the shapes in the middle show me, that 8 lines are missing in the top.
Then could you post the correct picture/photo when wrap around happens?
Sure. To better show the effect I took one overview picture of the test-picture displayed in the panel and two detail pictures from the top and the bottom.