Open matejdro opened 3 years ago
I have a really similar problem.
Behavior: after resuming from display timeout the screen flickers to black in my case. The problem stops when a portion of the screen is redrawn. So I usually force a complete redraw by going full screen and back with current window.
I also have two screens. but it happens also when using only one even if less often.
In my case I am using Arch with intel graphics and i3wm. Using picom backend glx.
Happens on AMD with radeonsi. For me this was caused by glx-no-stencil = true
but that's missing from your config. Though I've just ran into it again after setting my DefaultDepth
to 30 and installing the xf86-video-amdgpu
package.
Reproducer: sleep 1; xset dpms force standby
, then move your mouse or press a key.
Looks similar to this one #578
I also have two monitors, both start flickering fast (in my case the whole screen except i3bar
turns black and turns back on) after resuming from idle, have to restart picom to fix it.
I have Intel integrated graphics, running Arch Linux, i3wm, picom-git (latest commit), xorg with modesetting driver.
My picom.conf
here
update: I just enabled --experimental-backends
and this problem is gone.
update: I still encounter this issue from time to time, but it's not as frequent as it used to be. Can't figure out why ¯\_(ツ)_/¯
happends here too with picom from git on arch with intel gpu with xf86-video-intel , config here https://gist.github.com/gulafaran/e7849391fd02591cb6f97e6e6281d509
@matejdro Just a copy of my comment on #578 here
Adding
glx-use-copysubbuffer-mesa = true;
in the config fixes the issue.
Somehow the problem persists, no matter the value of the glx-use-copysubbuffer-mesa
setting.
@pjanx I can confirm for my system it works flawlessly. I tried it various times.
I am using a fork of picom by ibhagwan along with i3.
After quick check, https://github.com/yshui/picom/issues/603#issuecomment-841095642 workaround appears to work! Will test a bit more and report if anything goes awry.
I can confirm that the workaround "glx-use-copysubbuffer-mesa = true;" won't solve it for me using xf86-video-ati/mesa 21.2.1 (Arch Linux). The only option for me is to fallback to the very slow xrender backend.
Same for me, this bug is really annoying :/
Using glx-use-copysubbuffer-mesa = true;
does not solve the issue. I use Arch Linux with picom installed from the official Arch package (v8.2
). The bug happens on all window managers I tested: dwm, spectrwm and xmonad.
I have no GPU card, only an intel CPU (with its graphic chipset) so I use mesa
.
To avoid it we can disable the standby monitor logic by DPMS via an X11 config. But this is not a good solution.
Edit: same observation on the git version.
Platform
Manjaro Linux amd64
GPU, drivers, and screen setup
Radeon 5700XT, xf86-video-amdgpu 19.1.0-2, mesa 20.3.4-3.
two monitors configured side-by-side with xrandr (issue usually happens on both monitors - flicker mashes workspaces from both monitors).
glxinfo.txt
Environment
Running i3 version 4.19.2 (2021-02-27)
picom version
vgit-dac85
Configuration:
picom.conf.txt
Switching backend from
glx
toxrender
fixes the issue, but then I loose vsync (which is the primary reason I'm using picom).Steps of reproduction
It does not reproduce 100% of the time, but often enough to be really annoying when it happens.
Expected behavior
Desktop should not flicker
Current Behavior
Desktop flickers between different i3 workspaces:
Killing picom stops the issue. Manually switching workspaces will also fix portions where screen will be redrawn (but some areas like the polybar tray area will keep flickering).
Other details
I've tried capturing logs, but picom made no log entries from screen timing out to flickering started. Is there a way to increase log verbosity? I couldn't find the switch.
Display blanking settings (from
xset q
: