sway

sway copied to clipboard

• Sway Version:

  • sway version 1.5-5c67d997 (Aug 1 2020, branch 'HEAD')
  • Also tested sway-1.5, with no change

• Debug Log: sway-adaptive-sync.log

• Configuration File: sway_minimal_config.txt

• Other system information:

  • Radeon RX 5700 XT
  • mesa git
  • xserver git
  • wlroots git
  • Kernel: amd-staging-drm-next (also tested older versions from a few months ago)

• Description: Adaptive sync doesn't work in fullscreen mode with XWayland with some applications.

Steps to reproduce:

1. Launch sway
2. Run glxgears with strangle 60 glxgears to limit framerate below maximum (pick a lower value if you have a 60hz monitor)
3. When first launched, glxgears will be in windowed mode and will show 60 hz (or 120 hz with LFC) on monitor display.
4. Press Win + f to toggle fullscreen, and refresh rate on monitor OSD will jump to 144hz.
5. Press Win + f to go back to windowed mode, and refresh rate on monitor OSD drops to the correct 120hz.

It's likely a regression somewhere since this has worked correctly in the past. It's possibly an XWayland issue since it seems to be limited to X programs (I tested Retroarch which is Wayland native, and it doesn't exhibit the issue). However, it doesn't seem to affect all XWayland programs (e.g. Subnautica + DXVK doesn't have the issue, but Wonder Boy: The Dragon's Trap + DXVK, does.)

• Other notes
  • It affects GL and Vulkan (RADV).
  • The issue doesn't occur with XMonad.
  • Sometimes, adaptive_sync breaks completely requiring a Sway restart and possibly a reboot, although I'm not sure if this is a Sway issue or not.
  • I also get a million [glfw error 65544]: Wayland: fatal display error: Broken pipe messages when exiting Sway, and I have edited out most of them from the log since the log would be multiple GBs otherwise.

EDIT: RPCS3 compiled with Wayland support is another app that doesn't seem to exhibit the issue, so more evidence that it's XWayland limited.

I just tested this myself: sway-git, wlroots-git: xorg-server-common-git 1.20.0.r703.gaac28e162-1 xorg-server-xwayland-git 1.20.0.r703.gaac28e162-1 Broken. Same behavior as you described.

If I revert just xwayland to xorg-server-xwayland 1.20.8-3 adaptive sync works as expected in fullscreen.

I've noticed a few other odd adaptive sync issues with current Xwayland git (Path of Exile has black 'banding' if you have vsync turned off) so it looks like there may be some sort of regression there.

Good to see it's not just me. I'm not sure how to go about doing a regression test with XWayland, seems like it would be pretty inconvenient but I'll look into it. Maybe just hackily replacing the system Xwayland will be enough.

Found the regression:

commit d6558477d7a264c2132bc977b51d80fc0277d1e0
Author: Simon Ser <[email protected]>
Date:   Tue Jun 2 15:40:16 2020 +0200

    xwayland: allow using linux-dmabuf with DRM_FORMAT_MOD_INVALID
    
    When the linux-dmabuf protocol is available, prefer it over the old
    wl_drm protocol. Previously wl_drm was used when modifiers aren't
    supported, however linux-dmabuf supports formats without modifiers too.
    In this case, linux-dmabuf will send a DRM_FORMAT_MOD_INVALID modifier
    for each supported format [1].
    
    This allows compositors to better handle these buffers, getting a
    DMA-BUF and implementing features like direct scan-out.
    
    A similar logic has been implemented for EGL [2].
    
    DRM_FORMAT_MOD_INVALID is now stored in the xwl_screen->formats list.
    glamor_get_modifiers still returns FALSE with zero modifiers if the
    only advertised modifier is DRM_FORMAT_MOD_INVALID.
    
    [1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/fb9b2a87317c77e26283da5f6c9559d709f6fdcd
    [2]: https://gitlab.freedesktop.org/mesa/mesa/-/commit/c376865f5eeca535c4aa8e33bcf166052c1ce2f2
    
    Signed-off-by: Simon Ser <[email protected]>
    Reviewed-by: Michel Dänzer <[email protected]>

 hw/xwayland/xwayland-glamor-gbm.c | 8 +++----- 

Reverting the commit works around the problem.

I also get a million [glfw error 65544]: Wayland: fatal display error: Broken pipe messages when exiting Sway

Sounds like a GLFW bug when the Wayland connection is broken, but it's completely unrelated.

Maybe just hackily replacing the system Xwayland will be enough.

wlroots searches for Xwayland in your PATH, so you should be able to add a symlink in e.g. ~/bin to your locally-built Xwayland executable.

Found the regression

Eh, that's interesting. I have no idea how this can affect VRR.

@zakk4223 Can you also provide debug logs?

~~Can you try adding a return false; on this line and see if it works around the issue? https://github.com/swaywm/sway/blob/8fb9f3b7119e263edd1b7f857341d6ea9f3410e3/sway/desktop/output.c#L550~~

Err, nevermind. The refresh rate jumps to the max, it doesn't drop.

Can you add this script to your PATH as Xwayland so that it overwrites the system Xwayland, and then collect debug logs:

#!/bin/sh

export WAYLAND_DEBUG=client
exec /usr/bin/Xwayland # or path to your local Xwayland binary

~Sway logs with WAYLAND_DEBUG set.~ Nevermind, these logs captured the completely broken adaptive_sync that sometimes occurs. I'll come back with another log for the issue at hand.

Logs for the main issue.

sway_debug_glxgears.log

Default config with a clean user. Started sway, enabled adaptive sync, started glxgears and then fullscreened it.

Regarding the secondary issue of adaptive_sync breaking completely, I've found that I can't reliably set the primary adaptive_sync mode if the secondary monitor isn't already set to the target value. I.e. if I want to set adaptive_sync = enable on the primary monitor, the secondary monitor needs to first have adaptive_sync enabled. The same applies if I want to disable adaptive_sync (the secondary monitor must first have its adaptive_sync disabled). To be clear, if I don't do this it works intermittently, just not every time.

This applies no matter which monitor is the primary or secondary.

Anyway, will try and make a full report for this issue later.

This doesn't appear to be limited to Xwayland windows, I can reproduce it with mame configured to use wayland (via sdl). Verified the window is not X11 (via the braindead xeyes test).

Same behavior. If I start it windowed the display refreshes at the game refresh rate. If I fullscreen it display starts reporting 160hz.

You might be running into this issue instead, which affects both Wayland and XWayland. I don't think this issue existr anymore as I don't have any issues once the offending commit in the other report is reverted.

Yep. Reverting to either kernel 5.10.X or mesa 20.0.3 fixes it. It's not Vulkan specific either, OpenGL applications are impacted also.

What's odd is not all of them are; some games still have proper adaptive sync behavior even on 5.11.X/21.1

Actually it seems my results are inconsistent. Still running kernel 5.10.26 with mesa 20.3.4. Fullscreen glxgears/vkcube limited to 55fps results in the display being driven at 160Hz when they are fullscreened. If they are windowed the display runs at 55hz.

I've attached the output of drm_info. One when the glxgears window is the only window on the output, and another when it is fullscreened with meta-f. There are three displays, the glxgears instance is displaying on the 3440x1440 monitor.

It was working earlier. I've tried rebooting (cold reboot even) restarting sway etc. One time it just spontaneously started working after I did some other work, so maybe there's a trigger somewhere. I'll keep flailing around to try and narrow it down

drm_info_window.txt drm_info_fscreen.txt

Flailing around paid off!

First, an observation:

setting WLR_NO_HARDWARE_CURSORS=1: run strangle 55 glxgears. Display is reporting 55hz. Fullscreen glxgears: still 55hz. Move the mouse cursor off that display: 160hz. Move mouse cursor back to that display: 55hz. mame still runs at max refresh rate (I think it hides the cursor entirely, maybe that's why?)

what fixes it. WLR_DRM_NO_ATOMIC=1

With that set, fullscreen mame, glxgears, vkcube, etc etc result in the display refresh rate matching the 'update' framerate. Cursor state/position etc doesn't matter.

Is this related to direct scan out? It seems anytime I see the debug message about enabling direct scan is when the refresh rate issue comes up. I guess NO_ATOMIC means no direct-scan out?

Any additional utilities you'd like me to run to generate debug info?

@zakk4223 WLR_DRM_NO_ATOMIC=1 fixed my adaptive sync issues as well, thanks a bunch for finding this workaround.

I was having an issue with adaptive sync not working in fullscreen games as well, however only in xwayland vulkan applications. Running vkcube in wayland native mode adaptive sync works as expected in fullscreen mode, however forcing vkcube to run in xwayland causes adaptive sync to not work in fullscreen. glxgears is not wayland native from a simple xeyes test, and adaptive sync works as expected in fullscreen. I have not tested a wayland native opengl game yet. Also tested in Doom 2016 via proton, using the opengl api adaptive sync works as expected, and switching to Doom's vulkan api breaks adaptive sync in fullscreen. So, for me, this issue is only present in xwayland applications using the vulkan api. However, WLR_DRM_NO_ATOMIC=1 does fix adaptive sync in the situations where it's broken, from what I can tell.

I'm on sway-git and wlroots-git from the chaotic aur on Arch, kernel 5.11.11 (also tested on 5.12rc5). Although I am using an amd 6700 XT, I am on mesa 21.0.1 and not 21.1.0_devel so I don't have the issue mentioned in this comment https://github.com/swaywm/sway/issues/5601#issuecomment-813803301

Edit: noticing more now that using the legacy drm interface, with WLR_DRM_NO_ATOMIC=1, results in a more jumpy adaptive sync, as well as that my screen flickers, or blinks, extremely fast, even at idle (with the refresh rate idling at 48 hz). This is the same issue I was having w/ my secondary monitor with adaptive sync turned on (even with atomic display not disabled, so I have adaptive sync turned off on that monitor), just less noticeable.

I think I'm going to turn atomic display back on and just live without adaptive sync in vulkan xwayland games for now, as the negatives of the legacy drm outweigh the positives of using it for me. Hopefully finding the workaround will eventually lead to a fix.

Okay, I'm getting the issue with X Vulkan apps again now as well (and with the same workaround being WLR_DRM_NO_ATOMIC=1). So this one may be a new regression, as I didn't have the issue with vkcube in the past. The Wayland version is segfaulting for me right now so I'm not sure if that has the issue too.

Interestingly, setting no atomic seems to enable adaptive_sync unconditionally (adaptive_sync_status in get_outputs will be shown as disabled even though it's being used).

EDIT: Issue doesn't exist with Sway 1.5.1 and Wlroots 0.12.0, so it must be a regression in one of those. Probably shortly before Sway 1.6/wlroots 0.13.0 as I haven't had any issues until recently, at least it couldn't be earlier than the Mesa report I made a month ago.

Bad commit appears to be: commit d9cae04ffc3140408f2604eeff7d4776fe8d9548 Author: Simon Ser [email protected] Date: Tue Mar 23 00:06:40 2021 +0100

linux-dmabuf-v1: always advertise support for implicit modifiers

Some clients (like Xwayland) will fallback to wl_drm if the compositor
doesn't explicitly advertise support for implicit modifiers, even when
the compositor supports explicit modifiers. This behavior sounds correct

Reverting commit works around the problem with X vkcube at the least. The other issue in Mesa still applies, so both need to be reverted on >= 5.11 kernel and mesa-git.

This is either a very complex set of conditions, or there are multiple bugs producing the same behavior. I downgraded to sway 1.5.1, wlroots 0.12.0, mesa 20.3.4 and kernel 5.10.26

both vkcube and glxgears still had the issue. mame had it in both x11 and wayland video drivers. I tried a few steam games and they all seemed to behave correctly in fullscreen.

I then downgraded Xwayland to 1.20.10, and vkcube, glxgears and mame+x11 were fixed. mame wayland was not.

I'm using an RX Vega56. I also have an RX480. I may swap to that as the primary adapter to see if it result in an differences in behavior. I will also try reverting that commit to see if it changes anything on my side.

edit: went back to sway-git and wlroots-git. Reverted the above wlroots commit. No change in behavior, fullscreen glxgears/vkcube still run at max refresh when fullscreen. Same with mame

Yeah, it might be a different issue with Vega and Polaris. I suspect the issue I am encountering is broken modifiers (which fits with both the Mesa issue and the wlroots issue involving modifiers). I'll try and test some of the other AMD GPUs I have on hand.

I confirm I am experiencing this with my R9 fury card. Fullscreen apps do not alter the monitor's refresh rate.

My GPU is a R9 Fury, a Fiji card.

$ glxgears -info 
GL_RENDERER   = AMD Radeon (TM) R9 Fury Series (FIJI, DRM 3.41.0, 5.13.13-zen1-1-zen, LLVM 12.0.1)
GL_VERSION    = 4.6 (Compatibility Profile) Mesa 21.2.1
GL_VENDOR     = AMD

Setting either WLR_NO_HARDWARE_CURSORS=1 or WLR_DRM_NO_ATOMIC=1 before launching sway seems to fix the issue.

Reproducing with glxgears and libstrangle is quite easy, but I double-checked VRR works in windowed mode with Rise of The Tomb Raider on Steam via flatpak.

I have the same issue, native wayland apps work as expected (with a lot of flickering), xwayland fullscreen apps instead do not alter monitor refresh rate.

Setting WLR_NO_HARDWARE_CURSORS=1 WLR_DRM_NO_ATOMIC=1 before launching sway does not fix the issue for me.

System information

OS: ArcoLinux
Kernel: Linux 6.0.9-zen1-1-zen
Sway version: sway 1.7
Graphics card: AMD Radeon RX 480
Mesa driver: mesa 22.2.3
wlroots 0.15.1
xorg-xwayland 22.1.5

Can confirm that I'm seeing this with my RX 6800 XT and dual freesync monitors. Reproduced with Elden Ring, Soul Calibur VI, and vrrtest. In every case adaptive sync works when the application is in windowed mode. As soon as the application is fullscreened my monitor OSD reports max refresh rate.

System info:

OS: Arch Linux x86_64
Kernel: 6.1.2-zen1-1-zen
GPU: AMD ATI Radeon RX 6800 XT 
Mesa Version: mesa 22.3.2
wlroots 0.15.1
xorg-xwayland 22.1.7
sway 1.7

Also tried sway-git, wlroots-git, and mesa-git with no change in behavior. Setting WLR_NO_HARDWARE_CURSORS=1 and/or WLR_DRM_NO_ATOMIC=1 when launching sway does not fix the issue.

Found something interesting today while trying different wlroots variables. Setting WLR_DRM_NO_MODIFIERS=1 when launching sway resolves the issue for me.

Elden Ring, Soul Calibur IV, and vrrtest now have my monitor syncing to the application framerate while fullscreen. I don't know if there are any drawbacks to setting this variable, but all seems to work well so far.

Worth noting that I upgraded to sway 1.8 and wlroots 0.16.1 prior to testing this out, but doubt it's related to the fix.

Hmmm. Then it sounds like an amdgpu bug.

Disabling modifiers will slow down rendering a bit and decrease power efficiency.

Not sure what KDE is doing different with plasma wayland, but I don't have this issue with their implementation of adaptive sync. It works out the box when I enable it in the display settings. I'm quite new to investigating this stuff, but would that still indicate an amdgpu bug?

Depends whether they use format modifiers or not. Comparing drm_info dumps would tell.

Here's drm_info output running under sway without any extra launch variables. sway_drm_info.txt

If I'm understanding correctly, I'd also want to run the same under plasma wayland?

Setting WLR_DRM_NO_MODIFIERS=1 when launching Sway doesn't solve the issue for me, but I have a different GPU (RX480). Anyway, Hyprland has the same behaviour as Sway with adaptive sync, at least for me.

Does it help to disable direct scan-out?

Does it help to disable direct scan-out?

Setted this WLR_SCENE_DISABLE_DIRECT_SCANOUT=1 before launching sway but the behaviour is the same.