Is there a way to disable the inherent vsync in kwin?

Probably a hard one. Despite the fact that kde plasma’s settings manager has an option to “allow screen tearing in fullscreen”, that option probably only works with the supported hardware like nvidia. RPI users (like me) still resort to using X11 (which allows screen tearing) just for this reason. However, i want to use wayland at some point, and low powered devices like RPI (or other ARM based devices) definitely require this vsync to be disabled to prevent frame drops during video playback (60fps videos) or other 3d stuff (games).

I am doubtfull that KDE will help us in that regard as we are a very thin userbase.

Just throwing this out there hoping that someone might have some hint to actually achieve this.

The aim of wayland is to prevent tearing. That would be even worse for videos that drop frames but don’t tearing. It’s not for nothing that even the simplest pi have gone through wayland. For games it’s different, but there’s often an option. So trying to get tearing under wayland to gain in performance isn’t a good idea unless you’re sabotaging the wayland principle.

I am not trying to sabotage anything man :slight_smile: My experience tells me otherwise. Under x11 with screen tearing, i can watch 60fps 1080p youtube videos without any issues. And i don’t really care about the screen tearing, because video is smooth. But under wayland, the same video drops a lot of frames and become unwatchable. And i do believe, the culprit is the “unchangeable” vsync that is enforced. I can actually recreate a similar situation if i enable vsync under x11, the frames start to drop. Though not as bad as wayland, it is still similar. Chromium and Firefox are both affected by this. I have a 60hz monitor. 60fps somehow can not be synced with this monitor and i lose a lot of frames. In theory, it should be perfectly in sync right? Well in practice, that never works for us. Probably because of the browser overhead and the low powered cpu/gpu that we have.

PS: VLC works fine though. So maybe it is again another “videocore” issue.

From my personal notes; perhaps this will be useful:


Fix video tearing in Chromium based browsers

chrome://flags → enable:

#ignore-gpu-blacklist
  • Overrides software rendering list; enables GPU-acceleration on unsupported system configurations (Mac, Windows, Linux, Android)
#enable-vulkan
  • Use Vulkan as the graphics backend (Windows, Linux, Android)

Fix video tearing in Firefox based browsers

about:config → enable:

layers.acceleration.force-enabled
  • Default is false.

Regards.

Thanx but we have tried all of these (and then some) before. I actually have further proof that it is probably vsync causing the performance drop in my case when it comes to chromium at least. If i try the webgl sampes (fish bowl) in x11, i can get proper 60fps. The same page in wayland can give close to 30fps (not above it, but below). So it is dropping frames.

When RPIOS decided to ditch x11 and go wayland, it also lost a lot of this performance. So it is not just Manjaro ARM. The compositor of wayland is “locked” to screen refresh rate. Because this is a low powered machine in our hands, the video buffer probably can’t sustain 60fps continuously and drops some frames, and once that happens, the vsync tries to compansate by dropping a bunch more frames (which could make the video much smoother if not dropped) just to prevent screen tearing. This might sound a little vague but that is my understanding.

I think that RPI is not the kind of device that one can complain about screen tearing. So imo:

Having more frames is better than no screen tearing.
Smooth playback is better than no screen tearing.

You should try firefox (nightly for me) with

layers.acceleration.force-enabled true
widget.wayland.vsync.enabled false

and a user agent switcher because google is not evil…
https://www.youtube.com/watch?v=LXb3EKWsInQ
Of course, there are drop frames. But it’s watchable up to 2k 60 fps vp9 under wayland. And going to cinema mode and full screen means fewer frames are lost. I get better results with that than with chromium which is jerky. Otherwise, with yt-dlp well configured, it’s night and day in terms of quality and fluidity, but it doesn’t work with plugin (open with mpv with the right mouse button) in flatpak. It takes the best sound and the best quality.

1 Like

Honestly, as the KDE Plasma received new updates in the last few weeks, i am seeing less and less lag. I think KDE guys can really tame that wayland beast. I could never like firefox. It always felt clunky to me. I am not a fan of chromium either but it always runs faster and is more responsive to me. And all the alternatives (other than firefox) is basically a derivative of chromium anyway. I am running the flatpak version now. The last update broke aac decoding but hopefuly they will fix it. I have been waiting for months now for arch arm to come up with a new version but it seems like they just abandoned it.

I have Freetube, mpv and yt-dlp installed. I mostly watch youtube on freetube but if it is a 1080p 60fps video, freetube sometimes struggles. Then i open it with yt-dlp in mpv and yeah, it is smoother then. Freetube has the option to just open any video with mpv with just one click if you set it up.

you were asking for solutions to disable vertical synchronization. Firefox can and surpasses chromium with this option. As for the rest, I was just reminding you that a pi5 is efficient with a little manipulation up to 2k and that it’s not supposed to struggle to read 1080p whatever the format.

It is interesting that you claim firefox can override the vsync that is set by kwin (compositor). I will try it. But if firefox can do it, then that should mean it can be disabled in some way.