hyprlandCrashReport1261.txt
hyprlandCrashReport1681.txt

randomly crashing when opening and closing foot windows

tested it anyway, seems tearing is unable to trigger citing "next frame is not torn" in all instances I've seen. Ghost of Tsushima running in wine wayland shown below:

Then I tested with CEMU, playing The Legend of Zelda: the Windwaker HD (pretty sure this is fullscreen subsurface)
Tearing was unable to trigger here when I was focused on the game, moving focus to my secondary monitor froze the game, and then tearing went to true (still blocked by "next frame is not torn")

Moving focus back to the game, the game wouldn't recover from being frozen, switching workspace on that monitor to another and back to the game made it continue, with tearing now disabled:

activelyTearing: true means that it's active. "next frame is not torn" flag is flipped between frames and hyprctl doesn't catch it in active state, ignore this "blocker" for now. Probably will remove it from output later.

Both crash reports point to CPopup::breadthfirst called by CWindow::popupsCount which wasn't modified. The only difference is that CWindow::popupsCount can be called by hyprctl monitors now and probably hits some popups during destruction. n is a WP inside CPopup::bfHelper and it isn't checked before accessing n->m_children

hmm, the foot clients I opened were empty actually, I didn't have hyprctl monitors running in them, they were just in shell.

Tearing is working on wine-wayland now afaict, disabled VRR on my monitor and could notice tearing in some instances.

However not working on CEMU still with the aforementioned issue of it only triggering when not focussed on it for some reason

Does it randomly crash or always on close?
Always crashes on close for me. And in a strange way:

        # | ./build/Hyprland(_Z12getBacktracev+0x62) [0x563245d1d785]
                getBacktrace()
                /home/ujin/projects/Hyprland/src/helpers/MiscFunctions.cpp:746 (discriminator 2)
        #1 | ./build/Hyprland(_ZN14NCrashReporter18createAndSaveCrashEi+0x869) [0x563245ba3cef]
                NCrashReporter::createAndSaveCrash(int)
                /home/ujin/projects/Hyprland/src/debug/CrashReporter.cpp:200
        #2 | ./build/Hyprland(+0x902fed) [0x563245a78fed]
                handleUnrecoverableSignal(int)
                /home/ujin/projects/Hyprland/src/Compositor.cpp:113
        #3 | /usr/lib64/libc.so.6(+0x43b30) [0x7f35dca43b30]
                ??
                ??:0
        #4 | ./build/Hyprland(_ZNK9Hyprutils6Memory12CWeakPointerI6CPopupE7expiredEv+0x14) [0x563245c2c9ba]
                Hyprutils::Memory::CWeakPointer<CPopup>::expired() const
                /usr/include/hyprutils/memory/WeakPtr.hpp:116
        #5 | ./build/Hyprland(_ZN6CPopup12breadthfirstESt8functionIFvN9Hyprutils6Memory12CWeakPointerIS_EEPvEES5_+0x38) [0x563245c1fcaa]
                CPopup::breadthfirst(std::function<void (Hyprutils::Memory::CWeakPointer<CPopup>, void*)>, void*)
                /home/ujin/projects/Hyprland/src/desktop/Popup.cpp:348 (discriminator 1)
        #6 | ./build/Hyprland(_ZN7CWindow11popupsCountEv+0x78) [0x563245c5f67c]
                CWindow::popupsCount()
                /home/ujin/projects/Hyprland/src/desktop/Window.cpp:1325 (discriminator 6)

only quitting yea

Should be fixed now. Happened when opaque was called on an unmapped window.

Should be fixed now. Happened when opaque was called on an unmapped window.

yep fixed.

more info on the cemu issue, it seems like the tearingBlockedBy is null when the window is frozen if that helps

if you want to test cemu for free i've provided a basic homebrew pong app which you can run in the emulator without needing any firmware or official games. this can be used to reproduce the issue on your side (run the .elf file in cemu)
pong.zip

the fps is unlocked here but still repro'd the issue for me

EDIT: whilst the window is frozen if i move my mouse it unfreezes. freezes again when cursor is still

This PR doesn't fix DS/tearing in general. Only makes single subsurface case acceptable for the DS/tearing code. And makes it easier to debug. So it'll be obvious when DS/tearing doesn't work due to config settings ("user settings", "window settings"), due to some other intentional internal check or due to something being broken (blocked by "null"). Internal checks and broken stuff are being fixed in #10020
If cemu doesn't freeze with this PR when tearing is disabled then I'd leave it as is since tearing doesn't work for cemu either way. Try cursor:no_hardware_cursors = 1, #10020 disables them when tearing is active.

hey if you want to you can cherry pick this commit from my old pr #10020,
It seems relevant to this pr and I don't really feel like rebasing mine for the millionth time

hey if you want to you can cherry pick this commit from my old pr #10020, It seems relevant to this pr and I don't really feel like rebasing mine for the millionth time

that single commit doesn't seem to be enough. and there a lot of changes overall. better to cherry pick/merge/rebase in a separate PR after this one is merged

I tried this PR and Hyprland crashes for me 1-2 seconds in.
hyprlandCrashReport512.txt

I tried this PR and Hyprland crashes for me 1-2 seconds in. hyprlandCrashReport512.txt

fixed

I have been testing games with wine-wayland + HDR.
Tearing works now!
Direct Scanout works now! (There's a noticeable decrease in latency when moving the mouse)

Issue is if you have both enabled.

hyprctl monitors wil list Direct Scanout as blocked by tearing which is correct, BUT, the game will be frozen on one random frame. Sometimes it will render a few every few seconds and then stop, sometimes it'll just be a black screen.

Turning either one off, makes the other one work flawlessly.

Bonus fix (I'm not 100% sure it worked before), VRR works flawlessly with the wine-wayland + HDR combo. In the past, it'll work for a bit (like until the main menu of the game I can see the refresh rate adjusting), but when in-game, it would actually be stuck at max refresh rate. VRR worked fine on Xwayland btw, it was only on wine-wayland where this issue existed.

generally lgtm just tests would be nice

any docs on how to write and run tests?

yeah https://wiki.hypr.land/Contributing-and-Debugging/PR-Guidelines/#testing-and-ci

Some tests might be broken. Couldn't verify them because for some reason I get

Monitor HEADLESS-2 (ID 1):
        0x0@60.00000 at 0x0
        ...
        active workspace: -1337 (snap)
        special workspace: 0 ()
        reserved: 0 0 0 0
        scale: 1.00
        transform: 0
        ...
        availableModes: 1920x1080@0.06Hz 

Should be ok with the correct monitor setup.
Is it possible to add tearing support to a headless output?

maybe its the snap test not coming back to workspace 1?

Fixed most of the issues. Hard to make a sensible test without some hw features for headless outputs.

The only issue I have with this PR still is that tearing + DS makes it stop rendering, even though DS is deactivated according to hyprctl monitors due to tearing. If I disable DS, tearing works and vice versa.

Also is there a reason tearing should be preferred over DS? Shouldn't DS take precedence?

edit: Also, with just tearing enabled and not DS, it's bit wonky. It will freeze on a frame until I toggle fullscreen a few times.

ALL THESE TESTS ARE DONE WITH wine-wayland and HDR.

The activation logic should be the same as on main. So the same issues should be present on main for apps that don't need this subsurface fix.
No particular reason to prefer tearing, it's the same on main. DS is usually a global setting and tearing is per-app through immediate rule, makes sense to prefer tearing when it's explicitly requested for an app.
Those issues and interaction between tearing and DS will be fixed after this PR.

HDR should produce more reliable results. CM for SDR DS doesn't exist atm and some SDR formats can't be used with DS at all.

This PR was meant to fix DS in wine-wayland on my nvidia setup and I am not interested in tearing. Ironically tearing seems to be working on every setup and DS works on mesa drivers. Might also work with some other videocard and nvidia driver version combos. No luck for me

is this ready or...?

Ready