Tearing with rotated screen

[aromanro]

Platform

Raspbian on a compute module 3, output of uname -a
Linux raspberrypi 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux

GPU, drivers, and screen setup

vc4-kms-v3d
a custom DSI panel that starts in 800x1280 mode
rotated display to landscape (1280x800) with xrandr --output DSI-1 --rotate left

Environment

I tried this with several different setups, it behaves the same.
For example, xfc4 and lxde.
vsync is working fine when the screen is not rotated, but once it's rotated, windows tearing occurs, very visible if dragging the window or scrolling.

picom version

It's compton, the one it's obtained on raspbian with apt install compton.
Trying compton --diagnostics says this:

compton: unrecognized option '--diagnostics'
compton (0.1~beta2+20150922)
usage: compton [options]

followed by the available options.

Configuration:

compton --backend glx --vsync opengl-swc --config /dev/null

But I tried a lot of other options with the same (or worse) results.
xfce4 comes with its own compositor, but that one does the same, so I switched to compton, hoping that it will work better.

Steps of reproduction

1. Enable compton as above, at autostart (if xfce4 is used, its own one must be disabled).
2. Rotate the screen.
3. Drag a window around.

Expected behavior

No tearing, as in the non rotated case.

Current Behavior

Youtube video:
https://youtu.be/e4KI9Xr45q8
Sorry for the bad focus, but the effect is visible nevertheless.

More info

Apparently the issue does not exist if using Wayland/Weston. But that option has some other issues so it might not be so good.

[yshui]

You are not using picom.

[aromanro]

No, I'm not.

But I understand that Compton development ceased and this is where the development effort moved. I was hoping that somebody would be kind enough try to rotate the screen and confirm or infirm this issue for picom. Especially one that has it compiled for Raspbian.

[yshui]

@aromanro You can try picom and see if it helps. Building instructions are listed in the README.

[aromanro]

Probably I'll do that, but I was hoping somebody already knows about such behavior.
Thank you!

[aromanro]

picom exhibits the same issue.
It took me a while, since I needed to cross compile it, but I have it working now.

I'll do more tests and provide more info later.

[aromanro]

I'll add only the things different from the first comment here:

picom version

Output of picom --diagnostics is:

**Version:** vgit-def63

### Extensions:

* Shape: Yes
* XRandR: Yes
* Present: Present

### Misc:

* Use Overlay: Yes
* Config file used: None

### Drivers (inaccurate):

modesetting  

Configuration:

Currently is:
/usr/local/bin/picom --backend glx --vsync

But I tried various flags, with similar issues. For example, I tried --experimental-backends, also not only the glx backend but xrender, too. I also tried --no-use-damage but it does not seem to help.

[yshui]

Does vsync work when the screen is not rotated?

[aromanro]

Yes.

[aromanro]

I suspect this is not an issue in picom, but something originating somewhere else in xorg.

Does it work ok on other platforms, when the screen is rotated?

[yshui]

Same problem on Intel :(

what picom does is simply ask OpenGL to do vsync, when it broke, it's almost always the drivers' fault, and there is nothing much picom can do. It's better to report this bug upstream.

[aromanro]

I'm not sure that would explain why wayland does not exhibit the same issue, though. Isn't it using the same video driver and opengl lib?

[yshui]

@aromanro I was more talking about the driver in Xorg, instead of the underlying kernel video driver.
Yes, they are using the same underlying kernel drm driver, but there are code in Xorg that talks to the drm driver, which can also be considered a driver (the xf86-video-* stuff).

As for opengl, the higher level stuff is the same, but the platform dependent part (EGL, GLX) is different

[yshui]

I would suggest opening a bug report against xserver, as I assume you are using the modesetting driver? I can see the same problem with the modesetting driver on Intel graphics as well. (the problem could also be in mesa, but less likely)