Screen tearing? about voidrice

[sea4nl]

I had the same issue and solved it with the Intel driver.

I found this guide: https://github.com/chjj/compton/wiki/vsync-guide and it says:
"First of all, compton cannot do VSync better than your driver could. For vesa and other pure-software or broken drivers, or when you turned off the hardware acceleration in your driver, you shouldn’t expect much about VSync."

So I enabled the option "Tearfree" for my Intel drivers, giving me good results.
I made the following file: /etc/X11/xorg.conf.d/20-intel.conf and added the following:

Section "Device"
      Identifier    "Intel Graphics"
      Driver        "Intel"
      Option       "Tearfree"      "true"
Endsection

[x-t]

Intel fixes were already stated.
In my experience none of the ATI/AMD cards had screen tearing.
And for Nvidia there's a section on the Arch wiki for that:
https://wiki.archlinux.org/index.php/NVIDIA/Troubleshooting#Avoid_screen_tearing

[samuelhnrq]

What is your GPU? If you use the integrated Intel one, I know there is some kind of Xorg flag, have you tried this?

[LukeSmithxyz]

Yeah, that's what I have, but considering that a lot of people are using these dotfiles, I'm sort of curious if there's some kind of general setting I can enforce to maximize the number of users that don't have to tweak things.

[LukeSmithxyz]

If it means anything that particular solution on the wiki didn't work on my machine and would fail to start the X server.

[samuelhnrq]

Oh yes I remember running into the same issue, as far as I understood it, it happens because Xorg simply uses the generic mesa driver by default which the mesa Intel driver (i915) just happens to implement, but what I do am sure about is that the driver that who has all the fancy Xorg conf options is the xf86-intel one, whom is code-named 'intel' in the xorg config.

But I also remember it's not simply binary superior, I've heard it has some issues with the more advanced 3D rendering stuff because it's older, I personally never ran into any though, actually the contrary, I was also having some issues with xbacklight not recognizing my T430's 'back light property' witch the xf86 driver also fixed.

But all of that is kinda of irrelevant here, because such fix would need to be applied at a LARBS level, the compton options I know of that might be involved in fixing tearing are the vsync ones:

# Set VSync method. VSync methods currently available:
# none: No VSync
# drm: VSync with DRM_IOCTL_WAIT_VBLANK. May only work on some drivers.
# opengl: Try to VSync with SGI_video_sync OpenGL extension. Only work on some drivers.
# opengl-oml: Try to VSync with OML_sync_control OpenGL extension. Only work on some drivers.
# opengl-swc: Try to VSync with SGI_swap_control OpenGL extension. Only work on some drivers. Works only with GLX backend. Known to be most effective on many drivers. Does not actually control paint timing, only buffer swap is affected, so it doesn’t have the effect of --sw-opti unlike other methods. Experimental.
# opengl-mswc: Try to VSync with MESA_swap_control OpenGL extension. Basically the same as opengl-swc above, except the extension we use.
# (Note some VSync methods may not be enabled at compile time.)
vsync = "opengl-swc";

# Enable DBE painting mode, intended to use with VSync to (hopefully) eliminate tearing.
# Reported to have no effect, though.
dbe = false;

Because, AFAIK tearing happens because there are more frames then the refresh rate and the monitor just starts giving up on rendering them part way right? Enabling VSync (A.K.A FPS limiter according to your monitor) should fix it...

[LukeSmithxyz]

vsync = "opengl-swc" is already in the compton.conf now (although not the dbe = false; line if that would make a difference).

I'll also say that I've had users whose compton would fail to start with that vsync line, solved only by removing it.

[yurisuki]

i removed the whole compton.conf because of input drops and big latency in games, i only have the transparent terminal, but i hate that default behavior (fading)

[TomJansen]

Without compton I have screen tearing, but with compton I have input lag/drops. Anyone that knows a fix for the input drops (or why it is caused)?

[samuelhnrq]

@TomJansen how much input lag? Cause I mean if you mean "I recorded it with a 1000 fps slow mo camera and there I clearly 3ms more delay, unnaceptable" I don't think there is much that can be done

[TomJansen]

Well I think I didn't use the correct terms but I have lag in the terminal emulator. From a google search I found out that it could be an issue with compton

[yurisuki]

I do play a game named osu! through Wine (there is an open source version for Linux, but it's still in alpha) and having no input drops/latency is really important. (see here). The game has latency counter: without compton I have ~1ms latency and with compton I have ~4.2ms latency, so here I see a real reason to turn off compton. I don't really experience any screen tearing, so this was my conviction to get rid of it. I only miss having transparent, and I didn't find any alternative to compton which doesn't have input drops/latency.

EDIT: yes this also applies to the graphical tablet, this is basically usual input with people play (including me)

[LukeSmithxyz]

I'm going to close this issue. I was hoping there was a kind of one-size-fits-all solution that I could implement for everyone's system at once, but it's pretty clear that doing that via dotfiles is not possible. If I do add a universal and final solution to screen tearing, I suppose I'll have to do it in the LARBS install scripts based on the user's graphics hardware.

[luukvbaal]

Hey Luke, just wondering what was the reason you switched to xcompmgr and whether your current setup has no screen tearing using xcompmgr. I switched back to compton since I couldn't get rid of screen tearing using xcompmgr.

[LukeSmithxyz]

compton was continually causing problems for some users so I switched back to xcompmgr. The only reason I had originally used compton in the first place is because urxvt's transparency required it, but as these dotfiles don't use urxvt any more, it's no longer necessary.

I eliminate screen tearing by manually setting settings similar to what @sea4nl provided above.

[bridgesense]

Sorry to wake up an old topic, but this single thread covers it all as far as the screen tearing issue. I was using @sea4nl's solution for quite a while, but it seems that the kernel mode setting is the way to go with newer Intel hardware. The compton solution works, but it's a serious battery hog. "picom --backend glx --vsync" solved this issue too for an Intel UHD 620 GPU.

[swindlesmccoop]

Picom can solve this problem just fine in its config file, ~/.config/picom.conf
Just append vsync true; and it should fix tearing issues. Not hard on CPU or anything either.