You are not logged in.
Pages: 1
EDIT ON BOTTOM.
Hi, I’m facing an annoyng issue: I run games using wine-staging (5.18 with DXVK installed/enabled) on Manjaro Xfce; I run many old games which runs very fine, except one of these games: GTA SA, which suffer of a lot of screen tearing, so, to prevent screen tearing, I have to enable the compositor: xfconf-query -c xfwm4 -p /general/use_compositing -t bool -s true
When the Xfce's compositor is enabled, the tearing is gone, but the downside is that the compositor will cause a lot of stuttering in the gameplay, but is not the culprit the Xfce's compositor only: also if I use picom or I enable the option “TearFree” “true” in /etc/X11/xorg.conf.d/20-intel.conf I will still face the stuttering while gaming: I only have two choice: play with tearing or play with stuttering. Furthermore I also use libstrangle to limit the FPS, and this utility (strangle) also allows to set the vsync method:
strangle --help
For Vulkan the following rules apply:
0 - Force off
1 - Mailbox mode. Uncapped framerate
2 - Traditional vsync. Capped framerate
3 - Adaptive vsync. tearing at low framerates
I set -v 2, but doesn’t always work; I pinpointed when the strangle’s VSYNC works without the need of enabling any compositor: when xfwm4 crash.
From time to time, when I check the Journal logs (using journalctl -b | grep -i -E 'error|failed') I see
traps: xfwm4[1132] trap int3 ip:7ff718c1fdc4 sp:7ffce018e0d0 error:0
#4 0x00007ff718aa782b _XError (libX11.so.6 + 0x4382b)
The curious fact is that when this error occurs, the xfwm4 compositor is not enabled (I prefer picom), and I noticed that occurs when I have Gedit opened and i start to typing or I save a text file: I notice it not only by checking the timestamp of the log; I notice it also by the fact that I see a momentary/flash flickering of the screen, but, I repeat, the Xfce compositor is disabled!
And in such circumstance, after that xfwm4 report the crash in the log, I am able to set the VSYNC of strangle without the help of any compositor, so there is no tearing nor stuttering.
I found a thread on this forum about the same/similar error, but for me this doesn't made the system almost unusable:
https://forum.xfce.org/viewtopic.php?id=13679
I look for some hints: I'd like to have vsync enabled when gaming, without using any compositor (as I've said they cause a lot of stuttering); strangle works like a charme (to be more accurate: I run the game using a bash script, and before to launche the game, i pkill picom), but only when xfwm4 will crash.
I also tried to using MangoHud https://github.com/flightlessmango/MangoHud which, also this utility permits to force the VSYNC, but again, I am able to force the VSYNC only after that XFWM4 will crash...
Last edited by D.dave (2020-10-10 23:41:08)
Offline
Well, for now I found a "dirty workaround"; but before I summarize:
For execute Wine's games, I have two mandatory needs:
Disable/Stop the compositor (any compositor will introduce stuttering)
Avoid screen tearing.
To achieve the above points, I rely on libstrangle (now, instead, on MangoHud which can display various info during gameplay)
Eg, for DXVK Games, I set "vsync=3" which force Vsync for avoid screen tearing, and I don't need compositors, because as I've said compositors introduce stuttering.
Well, I can confirm that to force the VSync by using libstrangle or MangoHud I have to wait that xfwm4 will cause a coredump: is very odd and a weirdo thing...
However I reported the issue of xfwm4 on Gitlab:
https://gitlab.xfce.org/xfce/xfwm4/-/is … note_17167
So, my "dirty workaround" for being able to force VSync with libstrangle or MangoHud is to execute the following bash script to trigger the xfwm4 coredump in the log:
#!/bin/bash
pkill picom
sleep 4
xfconf-query -c xfwm4 -p /general/use_compositing -t bool -s true
sleep 4
xdotool key ctrl+alt+d
sleep 4
xfconf-query -c xfwm4 -p /general/use_compositing -t bool -s false
sleep 4
xdotool key ctrl+alt+d
sleep 4
picom -b
sleep 4
xdotool key ctrl+alt+d
sleep 4
xdotool key ctrl+alt+d
Offline
Pages: 1
[ Generated in 0.007 seconds, 9 queries executed - Memory usage: 528.21 KiB (Peak: 529.49 KiB) ]