Hi, experts
We have encounter a display shifting issue when test our board, the screen resolution is 1920x1080, it sometimes has a large offset in the x direction.
The origin image is as follows:
It is worth noting that the screen does not shift every time when I boot the system. The probability of the screen shifting is about 1/15. The offset of the image on the screen in the x direction is the same every time.
The display related device tree nodes are as following:
```
I have dump the registers of the LCDIF and MIPI DSI when the screen is shift, the values are as following:
32e80000: 00000000 ....
32e80004: 00000000 ....
32e80008: 00000000 ....
32e80010: 80000000 ....
32e80014: 04380780 ..8.
32e80018: 005a005a Z.Z.
32e8001c: 000a000a ....
32e80020: 000a001e ....
32e80024: 00010005 ....
32e80028: 00000000 ....
32e80030: 00000001 ....
32e80034: 00000001 ....
32e80200: 04380780 ..8.
32e80208: 00221e00 ..".
32e8020c: b5e00000 ....
32e80210: 00000000 ....
32e80214: 89000000 ....
32e60004: 80100400 ....
32e60008: 00000002 ....
32e6000c: 00000000 ....
32e60010: 91f80008 ....
32e60014: 00ffffff ....
32e60018: 3670707f .pp6
32e6001c: 01e00000 ....
32e60020: 84380780 ..8.
32e60024: f00a000a ....
32e60028: 00440044 D.D.
32e6002c: 02800013 ....
32e60030: 03000400 ....
32e60034: 01000000 ....
32e60038: 8b337fff ..3.
32e6003c: 00000000 ....
32e60040: 00000000 ....
32e60044: ff7fb5aa ....
32e60048: 000001ff ....
32e6004c: 0155541f .TU.
32e60050: 00004040 @@..
32e60078: 00010002 ....
32e60090: 00000000 ....
32e60094: 008049a2 .I..
32e60098: 00000000 ....
32e6009c: 00000000 ....
32e600a0: 000001f4 ....
32e600a4: 00000000 ....
32e600a8: 00000000 ....
32e600ac: 00000000 ....
32e600b0: 00000000 ....
32e600b4: 0000060c ....
32e600b8: 041e0d07 ....
32e600bc: 00050d09 ....
Could you help me see what's wrong on my platform? Thank you very much!
Snow
Best regards
Solved! Go to Solution.
Hi Zhiming_Liu
After deeply investigate, we found this issue indeed a bug in the mainline linux, and it has been fixed in linux-6.8, after apply that commit, this issue doesn't occurs after 200 times reboot.
Thank you for your help!
Zhou Liang
Best Regards
Hi @ZhouLiang1
Which display framework you are using? QT or other? or based on wayland?
Hi, Zhiming_Liu
Thank you for your help.
We are using `weston` to test the display, only show a background. I previously saved the drm buffer created by weston as a png image when the background image has a big offset, and found that the saved image was correct. so I think this is a driver related issue.
When the display shifting issue occurs, I restart the weston service, but the shift is always exist, but if I force off and on the card by the following command:
```
echo off > /sys/class/drm/card2-LVDS-1/status
echo on > /sys/class/drm/card2-LVDS-1/status
```
After these operations, the background on the screen displays normally.
Zhou Liang
Best regards
Hi @ZhouLiang1
What's the resolution of your original picture?
What's the resolution og the picture you dump from weston?
I think this should be weston issue, because the hardware is very simple. It receives display buffer(like 720p size) from userpace allocated. But if userspace give it bigger buffer size, like more that 800p. Maybe will exist such display issue.
You can try to resize original image size same as your panel size. And test again.
Best Regards
Zhiming
Hi Zhiming
I have used the image with the pixel of 1920x1080 to test the display, it still have the shifting issue, please see the attachments. One is the origin image, the other one display with x offset.
I also check the log of weston, the display mode is correct, the size of the frame-buffer also correct(1920x1080x4 = 8294400)
```
drm_output_init_pixman enter w= 1920, h = 1080..
1970-01-01T00:00:06.639231+00:00 valuemon64 weston[626]: [00:00:06.564] drm_fb_create_dumb 1920, 1080
1970-01-01T00:00:06.639330+00:00 valuemon64 weston[626]: [00:00:06.568] xxxx drm_fb_create_dumb: create_arg.size = 8294400, map_arg.offset = 8294400
1970-01-01T00:00:06.639424+00:00 valuemon64 weston[626]: [00:00:06.568] drm_fb_create_dumb 1920, 1080
1970-01-01T00:00:06.639519+00:00 valuemon64 weston[626]: [00:00:06.571] xxxx drm_fb_create_dumb: create_arg.size = 8294400, map_arg.offset = 16588800
```
Is this problem related to frequency configuration?
BTW, I just found the value of Master PLL PMS Value setting Register (MIPI_M_PLLPMS) is 0x00000000
32ec000c: 00000000
Could this be the cause of the problem?
Thanks
Zhou Liang
Best Regards
Hi @ZhouLiang1
How do you test this background display function?? with weston api? Can you share the test steps?
Hi Zhiming_Liu
I test the display using the following steps:
step1: Config the weston.ini
```
[core]
modules=systemd-notify.so
idle-time=0
shell=desktop-shell.so
pageflip-timeout=1000
pixman-shadow=false
[shell]
locking=false
panel-position=none
startup-animation=none
allow-zap=true
binding-modifier=super
background-image=/usr/share/helix-session/sun/splash.png
background-type=scale-crop
[keyboard]
keymap_layout=gb
vt-switching=false
[output]
name=LVDS-1
```
The background-image field configures the background image path.
Step2: Keep restarting the system to see if there is a display shifting problem. Currently, it may occur once about 20 restarts.
The weston is installed as a service in our system, when system starting, the weston will load the drm device and draw the background on the screen.
Zhou Liang
Best Regards
Hi @ZhouLiang1
I have tested it on EVK board with MIPI-HDMI bridge.
There is no such issue after testing ~40 reboot on Linux 5.15.y and Linux 6.1.y on i.MX8MPlus EVK.
You can test MIPI panel(without sn65dsi84) if you have MIPI panel and other display interface.
Best Regards
Zhiming
Hi Zhiming_Liu
Thank you for your support. We use Linux 6.5 to test our board. Currently the HDMI on our board isn't work, so I can test this issue by using the HDMI.
I did a test on my board yesterday, when the display issue occurs, I'm enable the TEST_PATTERN function of SN65DSI84, in this mode, the SN65DSI84 bridge will use the clock generated by DSI, but use the data generated by itself, and the output seems doesn't have x offset, you can check the attachment.
So I think the issue doesn't caused by the SN65DSI84.
Hi @ZhouLiang1
1. NXP maintain Linux6.1.y and Linux6.6.y, we never maintain Linux6.5.y, i think you are totally using MAINLINE kernel, because in our dtsi, the lcdif is using such compatible name "fsl,imx8mp-lcdif1", not "fsl,imx8mp-lcdif".. ONLY mainline kernel use one lcdif instance. Mainline kernel is not maintained by NXP, also the display framework.
2. MIPI DSI driver:drivers/gpu/drm/imx/sec_mipi_dsim-imx.c
LCDIF driver :drivers/gpu/imx/lcdifv3/lcdifv3-common.c
3. You should use Linux from NXP.
https://github.com/nxp-imx/linux-imx
4. We only support Linux from NXP.
Hi Zhiming_Liu
After deeply investigate, we found this issue indeed a bug in the mainline linux, and it has been fixed in linux-6.8, after apply that commit, this issue doesn't occurs after 200 times reboot.
Thank you for your help!
Zhou Liang
Best Regards
Hi,
Could you please share the commit id or patch (changes) or where the fix was been made in https://github.com/nxp-imx/linux-imx?
Even I'm facing the same pixel shift issue in imx8mm with lf-5.10 kernel and not able to see issue with lf-6.1 kernel. Is this fix made in lf-6.1? or in any branch of https://github.com/nxp-imx/linux-imx?
Best Regards,
Vinayak
I test my device using mainline linux, not the version of linux-imx, It fix in the following commits,
ff3d5d04db07e5374758baa7e877fde8d683ebab
Hi,
Sorry for the delay, The issue related to this commit:
ff3d5d04db07e5374758baa7e877fde8d683ebab