screen tearing when using display_rotate #837

christophevg · 2017-07-05T19:36:55Z

My RPI 3 setup (fully updated and upgraded) consists of an HDMI screen in portrait mode. So I used the display_rotate option in boot/config.txt to rotate the entire desktop.

This option/feature causes screen tearing (https://en.wikipedia.org/wiki/Screen_tearing). After some Googling, I found https://raspberrypi.stackexchange.com/questions/37280/distortion-while-moving-objects-in-portrait-mode, which describes the problem and proposes a solution to rotate the Xserver. This is indeed a solution, but the result is suffering from similar artefacts when updating the screen's content.

The screen tearing problem was most apparent when I wanted to display a 1080p movie using omxplayer. Only with the default display rotation, the video quality is good. As soon as I change the display orientation using the config.txt option, the video suffers terribly from the tearing.

Other sources address this problem to VSYNC (https://www.raspberrypi.org/forums/viewtopic.php?f=7&t=4451), but I don't seem to be able to find any way to influence this from my side.

My main question regarding this issue is: Is there a way to use the display_rotate option and avoid the screen tearing?

Thanks for your insights and feedback,
Christophe VG

The text was updated successfully, but these errors were encountered:

popcornmix · 2017-07-06T11:04:40Z

No. display_rotate is designed to copy/transpose a live buffer and so will suffer from tearing.

In the future we will be moving to an arm side kms driver and that should have the ability to rotate the display using standard X mechanisms which should allow rotation without tearing.

dividuum · 2017-07-10T17:21:06Z

Just adding: You can avoid tearing this if you rotate the video renderer output only instead of rotating the complete output with the display_rotate config.txt parameter. I'm pretty sure omxplayer has a --orientation argument. This will rotate the video only and you'll get no tearing.

popcornmix · 2017-07-10T17:22:43Z

Yes, if it only video you care about then see popcornmix/omxplayer#553

JamesH65 · 2017-12-22T15:26:56Z

The latest firmware has an extra config.txt option which may help with tearing a little bit. Here's all the display change config.txt options I added.

display_lcd_rotate -specifies rotate of LCD only.
display_hdmi_rotate - rotate of HDMI/composite only.
extra_transpose_buffer - allocates an extra transpose buffer when rotation of a display is required- can help with tearing

There is probably still a chance of tearing (I'm working on a fix for that) but it may be reduced.

riverscn · 2018-10-10T09:15:17Z

extra_transpose_buffer=1 still have tearing from my experience.

JamesH65 · 2018-10-10T09:19:32Z

Is it reduced by using the extra_transpose_buffer config item?

riverscn · 2018-10-10T09:30:09Z

I use a DPI connected HVGA(480x640).
display_lcd_rotate=1
extra_transpose_buffer=1
Simple test method: turn on "Black frame insertion" in RetroArch.

(extra_transpose_buffer=0)

(extra_transpose_buffer=1)
Tearing is still there, but different (smaller?).

JamesH65 · 2018-10-10T11:31:27Z

Hmm, I don't have retroarch. Or that screen, so not easy for me to look at.

riverscn · 2018-10-10T15:15:57Z

I hope kms driver come out soon 👍

JamesH65 · 2018-10-10T15:18:02Z

You can use the beta version now. It's been out for ages.

lwpz · 2018-12-29T08:38:38Z

I'm currently using kernel 4.4.50, are the new config.txt options working in this kernel version?? I'm facing similar issues.
Is it possible to advise where to look for the KMS drivers?
Thanks.

JamesH65 · 2018-12-29T13:51:33Z

You enable the KMS driver using raspi-config, but I suspect 4.4.50 might be too old. We are currently in testing of 4.19, and current release is 4.14, so you are a long way behind.

lwpz · 2018-12-29T14:04:01Z

Ok. Thanks. Does it mean that the new config.txt settings are also only available in 4.14+ kernel?

…

On 29 Dec 2018, at 21:51, James Hughes ***@***.***> wrote: You enable the KMS driver using raspi-config, but I suspect 4.4.50 might be too old. We are currently in testing of 4.19, and current release is 4.14, so you are a long way behind. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

JamesH65 · 2018-12-29T16:53:20Z

It's actually the firmware on the VC4 that parses config.txt for the transpose buffer, so if that is up to date, you should have that option. The latest KMS (name?) code needs a fairly recent kernel I believe.

lwpz · 2018-12-29T17:19:40Z

I see. I'm using a CM3 compute module purchased in Jan 2018. Is there anyway to check the firmware of the VC4? Else, I guess I could just try the commands to see if it does anything. Thanks.

…

On 30 Dec 2018, 00:53, at 00:53, James Hughes ***@***.***> wrote: It's actually the firmware on the VC4 that parses config.txt for the transpose buffer, so if that is up to date, you should have that option. The latest KMS (name?) code needs a fairly recent kernel I believe. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #837 (comment)

popcornmix · 2019-01-02T14:14:00Z

vcgencmd version should report the date of the firmware.

lwpz · 2019-01-03T12:30:20Z

vcgencmd version should report the date of the firmware.

Ok. I'll check this.

lwpz · 2019-01-03T12:33:27Z

I see. I'm using a CM3 compute module purchased in Jan 2018. Is there anyway to check the firmware of the VC4? Else, I guess I could just try the commands to see if it does anything. Thanks.
…
On 30 Dec 2018, 00:53, at 00:53, James Hughes @.***> wrote: It's actually the firmware on the VC4 that parses config.txt for the transpose buffer, so if that is up to date, you should have that option. The latest KMS (name?) code needs a fairly recent kernel I believe. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #837 (comment)

We had checked and found that kernel 4.4.50 does not support the above extra options. Kernel 4.14 will support it. For the KMS drivers, it's not working in 4.4.50, but working in 4.14. However, tearing issue is still there.

Is it possible to modify the HDMI driver to solve this issue? Just wondering....

JamesH65 · 2019-01-03T13:18:54Z

Can you copy&paste the results of the following to here so I can confirm the transpose buffers are working.

sudo vcdbg reloc

You should get entries for "transpose buffer0" and "transpose buffer1"

JamesH65 · 2019-01-03T13:24:14Z

should have mentioned, this is for the standard display drivers, not KMS, so using display_lcd_rotate and extra_transpose_buffer in config.txt

lwpz · 2019-01-04T01:21:02Z

should have mentioned, this is for the standard display drivers, not KMS, so using display_lcd_rotate and extra_transpose_buffer in config.txt

Yes. I understood, but enabling the KMS drivers didn't show any (improved) effect to tearing, even with or without the additional commands. The one that made a difference in the GUI desktop was basically kernel 4.14 with extra_transpose_buffer =1.

lwpz · 2019-01-04T01:21:46Z

Can you copy&paste the results of the following to here so I can confirm the transpose buffers are working.

sudo vcdbg reloc

You should get entries for "transpose buffer0" and "transpose buffer1"

Ok. I'll check for both 4.4.50 and 4.14.

lwpz · 2019-01-04T05:10:36Z

Can you copy&paste the results of the following to here so I can confirm the transpose buffers are working.
sudo vcdbg reloc
You should get entries for "transpose buffer0" and "transpose buffer1"

Ok. I'll check for both 4.4.50 and 4.14.

Please see the screenshots of both vcgencmd version and sudo vcdbg reloc

Looks like 4.14 has a transpose buffer0, even without the extra_transponse_buffer=1, but 4.4.50 has neither.

Comments welcome.

JamesH65 · 2019-01-04T11:51:54Z

OK, so 4.14 (actually, its the version of firmware that is important, 4.14 has a much more recent firmware. You could use the 4.14 firmware on 4.4 I think) is allocating a transpose buffer, you would get two transpose buffers if you have extra_transpose_buffer set. I would expect two transpose buffers to improve the observed tearing effect, although in my tests here, when running omxplayer over the framebuffer on rotated HDMI screen, I still get some tearing. I do not get the dark band, its only vaguely noticeable in the corner of the played back video.

lwpz · 2019-01-04T12:09:41Z

Do you mean the firmware inside the VC4 chip? Couldn’t really make out the firmware version, as the numbers (hex) were pretty long. It’s different tho. Did you want me to swap the kernel version and have a look? If the firmware is on the chip, is there anyway to program the VC4? Resolution wise we’re not even close to 1920x1080. I’d guess that’d explain why our moving images are more responsive to the extra buffer?

…

On 4 Jan 2019, at 19:52, James Hughes ***@***.***> wrote: OK, so 4.14 (actually, its the version of firmware that is important, 4.14 has a much more recent firmware. You could use the 4.14 firmware on 4.4 I think) is allocating a transpose buffer, you would get two transpose buffers if you have extra_transpose_buffer set. I would expect two transpose buffers to improve the observed tearing effect, although in my tests here, when running omxplayer over the framebuffer on rotated HDMI screen, I still get some tearing. I do not get the dark band, its only vaguely noticeable in the corner of the played back video. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

JamesH65 · 2019-01-04T13:07:11Z

The firmware is the start*.elf files in the boot folder. They are loaded on to the VC4 on startup. They should be backwards compatible, so you could take the start*.elf files from a 4.14 and put on a 4.4 and its should still work. However, I would backup the old files just in case as its not something we generally check. vcgencmd version will display the version number of the firmware (and date etc).

lwpz · 2019-01-04T13:16:28Z

Ok. I’ll give it a try and see. Thank you for your help. Let you know soon.

…

On 4 Jan 2019, at 21:07, James Hughes ***@***.***> wrote: The firmware is the start*.elf files in the boot folder. They are loaded on to the VC4 on startup. They should be backwards compatible, so you could take the start*.elf files from a 4.14 and put on a 4.4 and its should still work. However, I would backup the old files just in case as its not something we generally check. vcgencmd version will display the version number of the firmware (and date etc). — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

lwpz · 2019-01-08T07:44:35Z

We see the same issue with the 4.14 firmware files. Please see below.

On other applications in QT, we also see the same effect, when we're swiping and scrolling.

My finger was moving the screen and it's tearing..

Could you advise how to get it relevant files from Github?

PS I can also confirm that non rotated mode does not need the extra_transpose_buffer. Only in rotated mode

Thanks

JamesH65 · 2019-01-08T08:28:15Z

I'm just using a normal desktop 1920x1200 monitor, rotated, then playing 1080p video over the top.

Until I added the extra extra transpose buffer, I was getting slight tearing depending on where on the display the video was played. Note each transpose buffer takes 9MB, so using this will reduce the overall memory available.

The extra extra patch has been applied to the firmware tree, will be available in rpi-update in a few days. Not available in github as its closed source. I could probably let you have a custom version if it is urgent. Let me know.

JamesH65 · 2019-01-08T08:29:23Z

The tranpose buffers are only necessary on rotated displays. I also use the default GPU memory settings.

lwpz · 2019-01-08T08:48:27Z

I'm just using a normal desktop 1920x1200 monitor, rotated, then playing 1080p video over the top.

Until I added the extra extra transpose buffer, I was getting slight tearing depending on where on the display the video was played. Note each transpose buffer takes 9MB, so using this will reduce the overall memory available.

The extra extra patch has been applied to the firmware tree, will be available in rpi-update in a few days. Not available in github as its closed source. I could probably let you have a custom version if it is urgent. Let me know.

I see. We're using only up to SVGA (800 x 600) resolution, so I guess it is not.

We're now seeing transpose buffer0 & transpose buffer1. I presume there will be another transpose buffer on top the existing 2??

We see that the buffers take up 1.9MB per buffer. Could you confirm?

No issue. I understand that it is a closed source, due to licensing. I was thinking that it should be part of the /firmware section in github? In any case, if you could provide a version to us it'll be good, since we're doing some tests now. We can just confirm it for you?

Thanks.

lwpz · 2019-01-08T08:50:49Z

The tranpose buffers are only necessary on rotated displays. I also use the default GPU memory settings.

Rotated display only --> Got it!

Default should be 64MB right? Theoretically, would increase GPU to 128MB be necessary?

JamesH65 · 2019-01-08T09:37:36Z

Depends what other stuff is going on. If you are using the camera, you'll probably need to increase it, or using H264, maybe. Try it and see what happens.

JamesH65 · 2019-01-08T09:42:23Z

Yes, another transpose buffer will be added if you use extra_transpose_buffer=2 on the latest firmware. Each TB is about 10MB on the display I use - the size of the buffer is the size of the display, so a smaller display requires smaller buffers.

lwpz · 2019-01-08T09:52:26Z

Yes, another transpose buffer will be added if you use extra_transpose_buffer=2 on the latest firmware. Each TB is about 10MB on the display I use - the size of the buffer is the size of the display, so a smaller display requires smaller buffers.

Ok. I can try it out, if you're able to share it with me?

Size of buffer would make sense..

JamesH65 · 2019-01-08T10:02:10Z

Have uploaded the firmware set to here. This is all the different firmwares you would get on a normal install (standard, full, cutdown, debug). Not sure which one you are using, probably _x.

https://drive.google.com/open?id=1fsvwhbE1cxjJMT_L8_sypy8zwdiAIQc5

use extra_transpose_buffer=2 in config.txt

lwpz · 2019-01-08T12:54:19Z

Thanks. We'll update tomorrow. Preliminary impression it looks like tearing is not present now. Update again tomorrow.

Just a check. We tried the KMS drivers, but the tearing was still present and we still had to add the transpose buffer. If you need us to help you to test it, please do advise. We can allocate resources to do so.

JamesH65 · 2019-01-08T13:19:40Z

I have no knowledge of how the KMS driver works with this stuff. I would not expect the extra buffers to have any effect, I do not think that the KMS driver uses them, but could be wrong.

popcornmix · 2019-01-08T13:22:07Z

vc4_kms_v3d will not be affected by any firmware code changes. Any tearing solution will need to be handled on arm side.
vc4_fkms_v3d does use the firmware for displaying framebuffer, so may well be affected by this change.

lwpz · 2019-01-09T02:49:17Z

vc4_kms_v3d will not be affected by any firmware code changes. Any tearing solution will need to be handled on arm side.
vc4_fkms_v3d does use the firmware for displaying framebuffer, so may well be affected by this change.

Ok. I understand, which means that this buffer is probably mandatory to solve this issue, since it's GPU firmware related.

lwpz · 2019-01-09T12:43:46Z

Ok. Looks like the tearing issue is solved, using extra_transpose_buffer=2 and latest firmware (dated 7 Jan 2019). Let us run through and update by tomorrow.

Can I close the case if I wasn't the one, whom opened it?

JamesH65 · 2019-01-09T12:56:52Z

I'll close it. Thanks for testing. The code should be in rpi-update within a week or so, once it is you can move away from the custom firware you have at the moment. There's also a minor fix to this stuff, I didn't release all the buffers correctly on shutdown which isn't in your code, but will be in the release. I don't think it will affect you in the meantime.

kernel: ASoC: Add support for AudioSense-Pi add-on soundcard See: raspberrypi/linux#2793 kernel: USB Audio: generic DSD detection for XMOS-based implemtations See: raspberrypi/linux#2790 firmware: Added ability to have an third transpose buffer See: #837 firmware: isp: Correct the conversion tables changed in adding the gamma block See: #1084 firmware: raspberrypi_full variant: Drop unused Camplus sw stages bootcode: Reset WiFi and BT devices before resetting the expander See: #1088 bootcode: Fix Ethernet boot on a different subnet See: #1078

kernel: ASoC: Add support for AudioSense-Pi add-on soundcard See: raspberrypi/linux#2793 kernel: USB Audio: generic DSD detection for XMOS-based implemtations See: raspberrypi/linux#2790 firmware: Added ability to have an third transpose buffer See: raspberrypi/firmware#837 firmware: isp: Correct the conversion tables changed in adding the gamma block See: raspberrypi/firmware#1084 firmware: raspberrypi_full variant: Drop unused Camplus sw stages bootcode: Reset WiFi and BT devices before resetting the expander See: raspberrypi/firmware#1088 bootcode: Fix Ethernet boot on a different subnet See: raspberrypi/firmware#1078

popcornmix · 2019-01-09T20:40:50Z

Now in latest rpi-update firmware

lwpz · 2019-01-10T01:48:46Z

@JamesH65 @popcornmix
Thank you for your help. Always glad to do testing with the hardware. If you have anything else, please let me know.

This fixes the tearing when combined with the latest firmware see raspberrypi/firmware#837

ijash · 2019-07-30T17:39:13Z

i agree...... it happened to me too

JamesH65 · 2019-07-30T17:41:12Z

@ijash This issue has been closed for some time - do you still have a problem with the fixes outlined above?

ijash · 2019-07-30T18:41:59Z

@ijash This issue has been closed for some time - do you still have a problem with the fixes outlined above?

been updating it to latest firmware with rpi-update dated to this post and did the extra_transpose_buffer=2 in config.txt but still tearing.

JamesH65 · 2019-07-31T09:07:25Z

Are you using the vc4-fkms-v3d driver? If you don't need it, turn it off to see if that helps. The code path that uses extra_transpose_buffer is not used with this driver IIRC.

ijash · 2019-07-31T16:07:31Z

Are you using the vc4-fkms-v3d driver? If you don't need it, turn it off to see if that helps. The code path that uses extra_transpose_buffer is not used with this driver IIRC.

no, i'm not using that driver.

eightfivelabs · 2019-08-11T00:15:02Z

Hi all,
I have a Dell P2418HT 24" touchscreen connected to a 3b+ and am using rotate_display=1 in /boot/config.txt. The display rotates appropriately, but there is a slight flicker/tearing when opening new windows as the image is, seemingly, rotating. Is this a similar issue?

lwpz · 2019-08-11T02:03:27Z

Have you tried the extra transpose buffer in the config.txt. Does it show the symptom in non rotated mode? ⁣Regards lwpz

…

On 11 Aug 2019, 08:15, at 08:15, stuarth ***@***.***> wrote: Hi all, I have a Dell P2418HT 24" touchscreen connected to a 3b+ and am using `rotate_display=1` in `/boot/config.txt`. The display rotates appropriately, but there is a slight flicker/tearing when opening new windows as the image is, seemingly, rotating. Is this a similar issue? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #837 (comment)

popcornmix mentioned this issue Jul 7, 2017

mp4 fadein and fadeout flickering on the white spaces popcornmix/omxplayer#553

Closed

JamesH65 self-assigned this Dec 22, 2017

JamesH65 added the bug label Dec 22, 2017

JamesH65 closed this as completed Jan 9, 2019

tsoliman added a commit to tsoliman/Retroflag-GPi-case that referenced this issue Jul 20, 2019

update config.txt

79693ff

This fixes the tearing when combined with the latest firmware see raspberrypi/firmware#837

tsoliman added a commit to tsoliman/Retroflag-GPi-case that referenced this issue Jul 21, 2019

update config.txt

7bccb25

This fixes the tearing when combined with the latest firmware see raspberrypi/firmware#837

tsoliman added a commit to tsoliman/Retroflag-GPi-case that referenced this issue Jul 21, 2019

update config.txt

9fb92d9

This fixes the tearing when combined with the latest firmware see raspberrypi/firmware#837

screen tearing when using display_rotate #837

screen tearing when using display_rotate #837

Comments

christophevg commented Jul 5, 2017

popcornmix commented Jul 6, 2017

dividuum commented Jul 10, 2017 • edited Loading

popcornmix commented Jul 10, 2017

JamesH65 commented Dec 22, 2017

riverscn commented Oct 10, 2018

JamesH65 commented Oct 10, 2018

riverscn commented Oct 10, 2018

JamesH65 commented Oct 10, 2018

riverscn commented Oct 10, 2018

JamesH65 commented Oct 10, 2018 • edited Loading

lwpz commented Dec 29, 2018

JamesH65 commented Dec 29, 2018

lwpz commented Dec 29, 2018 via email

JamesH65 commented Dec 29, 2018

lwpz commented Dec 29, 2018 via email

popcornmix commented Jan 2, 2019

lwpz commented Jan 3, 2019

lwpz commented Jan 3, 2019

JamesH65 commented Jan 3, 2019

JamesH65 commented Jan 3, 2019

lwpz commented Jan 4, 2019

lwpz commented Jan 4, 2019

lwpz commented Jan 4, 2019

JamesH65 commented Jan 4, 2019

lwpz commented Jan 4, 2019 via email

JamesH65 commented Jan 4, 2019

lwpz commented Jan 4, 2019 via email

lwpz commented Jan 8, 2019 • edited Loading

JamesH65 commented Jan 8, 2019

JamesH65 commented Jan 8, 2019

lwpz commented Jan 8, 2019 • edited Loading

lwpz commented Jan 8, 2019

JamesH65 commented Jan 8, 2019

JamesH65 commented Jan 8, 2019

lwpz commented Jan 8, 2019

JamesH65 commented Jan 8, 2019

lwpz commented Jan 8, 2019

JamesH65 commented Jan 8, 2019

popcornmix commented Jan 8, 2019

lwpz commented Jan 9, 2019

lwpz commented Jan 9, 2019

JamesH65 commented Jan 9, 2019

popcornmix commented Jan 9, 2019

lwpz commented Jan 10, 2019

ijash commented Jul 30, 2019

JamesH65 commented Jul 30, 2019

ijash commented Jul 30, 2019

JamesH65 commented Jul 31, 2019

ijash commented Jul 31, 2019

eightfivelabs commented Aug 11, 2019

lwpz commented Aug 11, 2019 via email

dividuum commented Jul 10, 2017 •

edited

Loading

JamesH65 commented Oct 10, 2018 •

edited

Loading

lwpz commented Jan 8, 2019 •

edited

Loading

lwpz commented Jan 8, 2019 •

edited

Loading