Stuttering when using xrandr with scaled output
Platform
Arch Linux:
% uname -r
5.6.2-arch1-2
GPU, drivers, and screen setup
Dual graphics. Configured with Prime render offload. Using the modesetting driver for the Intel graphics.
Intel
GL_VERSION: 4.6 (Compatibility Profile) Mesa 20.0.4
GL_VENDOR: Intel
GL_RENDERER: Mesa Intel(R) UHD Graphics 620 (KBL GT2)
Nvidia
GL_VERSION: 4.6.0 NVIDIA 440.64
GL_VENDOR: NVIDIA Corporation
GL_RENDERER: GeForce MX150/PCIe/SSE2
xrandr
% xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x47 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 5 associated providers: 0 name:modesetting
Provider 1: id: 0x269 cap: 0x0 crtcs: 0 outputs: 0 associated providers: 0 name:NVIDIA-G0
% xrandr
Screen 0: minimum 320 x 200, current 4480 x 1440, maximum 16384 x 16384
eDP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 309mm x 174mm
2560x1440 60.01*+ 59.99 59.99 59.96 59.95
HDMI-2 connected 1920x1080+2560+0 (normal left inverted right x axis y axis) 527mm x 297mm
1920x1080 60.00*+ 50.00 59.94
Environment
I am using XMonad version 0.15 Nothing special happening here.
picom version
This happens with both, the picom and picom-git packages.
For the latter:
% picom --diagnostics
Version: vgit-b37db
Extensions:
- Shape: Yes
- XRandR: Yes
- Present: Present
Misc:
- Use Overlay: No (Another compositor is already running)
- Config file used: /home/max/.config/picom.conf
Drivers (inaccurate):
modesetting
Configuration:
Note: I am using picom to solve a tearing problem I observe when using the modesetting driver. The xf86-video-intel driver is not an option because it does not work with the Prime render offload method I use for dual graphics.
picom resolves the tearing issue flawlessly when using a single monitor or a second one which is unscaled. Since I use picom solely for this, all fancy visuals are disabled.
# Backend
backend = "glx";
# GLX backend
glx-no-stencil = true;
# Shadows
shadow = false;
# Opacity
inactive-opacity = 1;
active-opacity = 1;
frame-opacity = 1;
inactive-opacity-override = true;
blur-background-fixed = false;
# Fading
fading = false;
# Other
mark-wmwin-focused = false;
mark-ovredir-focused = false;
use-ewmh-active-win = true;
detect-rounded-corners = false;
detect-client-opacity = true;
detect-transient = false;
detect-client-leader = false;
refresh-rate = 0;
vsync = true;
dbe = false;
unredir-if-possible = false;
# XSync
# See: https://github.com/yshui/picom/commit/b18d46bcbdc35a3b5620d817dd46fbc76485c20d
xrender-sync-fence = true;
Steps of reproduction
- connect a second monitor and scale its output with
xrandr. e.g.:xrandr --output HDMI-2 --auto --scale 1.33x1.33 --right-of eDP-1 --auto - scroll in a window (e.g. browser) on the unscaled monitor or play a video with mpv and move the mouse over it
Expected behavior
The same behavior as with an unscaled output:
- no stuttering
- no flickering of the mouse Just a nice and smooth experience.
Current Behavior
The following observations can be made everywhere:
- the system appears unresponsive, but
- mpv does not drop frames (observed with
Shift+i) - screen recordings do not show the behavior outlined below
- thus, I conclude it is merely a presentation issue and not the system actually lagging
- mpv does not drop frames (observed with
Only observable on the unscaled monitor (here eDP-1):
- the mouse flickers when positioned in a part of the screen which is frequently updated (e.g. an mpv window or when scrolling in a browser)
- the
glxheadsdemo shows tearing (but not in a recording)
When picom is not running I do not observe these problems but the aforementioned tearing issues I am trying to resolve through the use of picom.
Stack trace
picomp does not crash.
Other details
As mentioned before, the problem cannot be recorded through screen capturing. I tried... I also tried playing around with the configuration options but did not find a solution.
i guess the exact look of stuttering will be helpful in understanding the origin of the issue and debugging it, so would be good if you can capture it using your mobile phone, for example.
also, does this happen if you disable offloading? try to use only intel gpu and then only nvidia gpu.
Yes of course! I wanted to check first whether this has been heard of before. I will make the recording later today.
Okay I made a video capturing all relevant cases. I had to split it into three uploads though:
- Only Laptop monitor is used: everything behaves normally: https://imgur.com/jNtR2jN
- External screen is used with normal resolution: everything behaves normally: https://imgur.com/s4890Q0
- External screen is scaled: the internal screen shows the aforementioned problems: https://imgur.com/XRuFUnQ
Some notes on part 3:
- the mouse is flickering while in regions where the screen is refreshed frequently
- the mouse even vanishes when moved in the top half of the
glxheadsdemo - the
glxheadsdemo shows visual artifacts near the top
Note: the glitch when switching to the external monitor was a fluke. I have not seen that happen before.
@mrossinek mouse cursor is not rendered by (not a responsibility of) the compositor, making me thinking this is a driver issue.
Okay interesting. Then I wonder though why this only happens while picom is running. And the tearing visible in the glxheads demo and the stuttering of the system when e.g. playing a video with mpv are still not explained by that, though.
I can't really image this, but could it be a problem due to the number of pixels having to be rendered?
@mrossinek vsync doesn't work under scaling isn't a surprise to me. Previously it was reported to not work when screen is rotated (#328). There was nothing picom can do there either, and a bug was reported to Xorg. I recommend you do the same thing for these two issues.
I will look into the stuttering.
Awesome thanks a lot! I did not notice #328 before. I will go ahead and report this bug to xserver just like discussed in #328. I will link here and to both of the rotating issues too, just for completeness.
Thanks for the fast reply :blush:
Link to xserver issue: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1013
Same issue with picom + scaled output on a secondary screen.
Reading the xserver issue linked in https://github.com/yshui/picom/issues/328, it mentions tearfree.
Enabling tearfree on the non scaled display fixes the issue with my setup:
$ xrandr --output eDP --set TearFree on --auto --output DisplayPort-1 --auto --scale 2x2 --right-of eDP
$ xrandr
Screen 0: minimum 320 x 200, current 6720 x 2400, maximum 16384 x 16384
eDP connected primary 2880x1920+0+0 (normal left inverted right x axis y axis) 285mm x 190mm
2880x1920 120.00*+ 60.00 +
DisplayPort-1 connected 3840x2400+2880+0 (normal left inverted right x axis y axis) 477mm x 268mm
1920x1200 59.88*+ 59.88