i3 flickers between workspaces after resuming from display timeout

matejdro commented 3 years ago

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 to xrender fixes the issue, but then I loose vsync (which is the primary reason I'm using picom).

Steps of reproduction

Leave PC idle for a while
PC will turn off the display due to PC being idle
Move a mouse / make a keyboard to wake the screen again

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:

output

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:

Screen Saver:
  prefer blanking:  yes    allow exposures:  yes
  timeout:  600    cycle:  600
DPMS (Energy Star):
  Standby: 600    Suspend: 600    Off: 600
  DPMS is Enabled
  Monitor is On

FrancescoCappio commented 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.

pjanx commented 3 years ago

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.

kanna5 commented 3 years ago

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 ¯\_(ツ)_/¯

gulafaran commented 3 years ago

happends here too with picom from git on arch with intel gpu with xf86-video-intel , config here https://gist.github.com/gulafaran/e7849391fd02591cb6f97e6e6281d509

deepjyoti30 commented 3 years ago

@matejdro Just a copy of my comment on #578 here

Adding

glx-use-copysubbuffer-mesa = true;

in the config fixes the issue.

pjanx commented 3 years ago

Somehow the problem persists, no matter the value of the glx-use-copysubbuffer-mesa setting.

deepjyoti30 commented 3 years ago

@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.

matejdro commented 3 years ago

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.

andyrtr commented 3 years ago

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.

doums commented 2 years ago

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.

kmikolaj commented 2 years ago

I know it's not helpful but option glx-use-copysubbuffermesa has been removed in v6.

yshui / picom