core/layers: top layers go below fullscreen windows, fix DS solitary by erstarr · Pull Request #15937 · hyprwm/Hyprland

erstarr · 2026-08-22T04:22:42Z

Describe your PR, what does it fix/add?

Title
Fixes #15881

Adds the config opt: misc:allow_new_top_layers_over_existing_fullscreen, which is self descriptive.

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

Default value for the new config opt is true to prevent stuff that relies on the "old" (config value true, not exactly old since there is a config for this but many ppl seem to consider = false to be a net improvement so mayhaps the config value could be removed in the future and = false could become the new standard. Or maybe wayland protocol will become less ambiguous and we'll just follow that) behaviour still works.

Hypractl Layers: Do not show a layer before it's properly mapped. It's a race condition if this is done ontop of making little sense: with hardware rendering the mapping happens fast enough for this to not matter but in github tests CI it incorrectly displays the alpha of the layers.

Is it ready for merging, or does it need work?

WIP

Notifications
Test

vaxerski · 2026-08-23T15:00:13Z

top layers over fs is expected. New ones should.

erstarr · 2026-08-23T15:02:44Z

top layers over fs is expected. New ones should.

#15881 disagrees with you.

Besides, dark, ritz, etc... also think so. The reason being there isn't a layer that's below fullscreen but above normal windows. bars etc... use top in noctalia wayle etc.. and when you cycle them in fullscreen, they render over fullscreen

Dregu · 2026-08-23T15:03:24Z

Yeah but nobody likes that. The protocol is stupid and there should be an option to not put any top layers above fullscreen. That's what overlay is for. So make this optional and everyone is happy.

LRitzdorf · 2026-08-23T15:05:29Z

Yeah. Having timing-dependent behavior like we currently do just feels buggy, even if the spec says it's technically okay. Users go "oh not this bug again" and toggle fullscreen, which they really shouldn't have to do

darkwater · 2026-08-23T15:07:39Z

The protocol doesn’t even prescribe that that should happen, it just describes that that’s what tends to happen.

It also means that if you don’t want notifications to pop up over fullscreen windows, there is no layer to place them.

Also when I ran into this I also saw it as a bug and went “welp gotta un-fs and fs my game again, which is annoying because it’s in hdr so it’ll blank out for a while”

e: As it stands now, there is no layer between tiled/floating windows and fullscreen windows.

erstarr · 2026-08-23T15:37:09Z

Added a config opt to control this. Defaults to true, which is the old behaviour

misc:allow_new_top_layers_over_existing_fullscreen

erstarr · 2026-08-23T21:59:28Z

I have absolutely no idea why the tests are failing in github CI.

Wait until layer spawn, wait until alpha is correctly set - all for naught. Layer tests are just not working on CI. Always passes in local.

vaxerski · 2026-08-26T12:55:59Z

I don't like it. But, if we're gonna change this, just make all tops below fs. Don't add a knob.

Dregu · 2026-09-03T15:03:23Z

Bug: Top layers that were never even visible still seem to block DS with "fadeout in progress" when closing under the fullscreen app. e.g. my bar normally shows up only when holding SUPER, this pr prevents that perfectly fine, but game goes out of ds for a fraction of a second when releasing SUPER and the bar closes.

Don't add a knob.

Bit of a conflict here, if "new top layers go above fullscreen" is indeed how the protocol should be interpreted, why should there not even be an option to follow the protocol?

erstarr · 2026-09-03T18:23:56Z

Bug: Top layers that were never even visible still seem to block DS with "fadeout in progress" when closing under the fullscreen app. e.g. my bar normally shows up only when holding SUPER, this pr prevents that perfectly fine, but game goes out of ds for a fraction of a second when releasing SUPER and the bar closes.

From your other comments in other discussions, the regressor is #15991 - this MR or anything it changes have nothing to do with that.

Dregu · 2026-09-03T18:43:49Z

My other comments elsewhere have nothing to do with layers fading. Without this PR the new top layer would obviously be visible on top of the game already, and the fadeout should block DS. It's definitely something this PR needs to account for when the fading layer isn't even visible.

LRitzdorf · 2026-09-05T04:15:45Z

Don't add a knob.

Bit of a conflict here, if "new top layers go above fullscreen" is indeed how the protocol should be interpreted, why should there not even be an option to follow the protocol?

FWIW, the protocol doesn't actually say which way this should go. All it really does is comment on how some compositors worked at the time of writing. Not to say that what other compositors do is totally irrelevant, but we certainly aren't violating the spec by saying "FS goes above the top layer always"

LRitzdorf · 2026-09-05T18:44:59Z

Bug: Top layers that were never even visible still seem to block DS with "fadeout in progress" when closing under the fullscreen app. e.g. my bar normally shows up only when holding SUPER, this pr prevents that perfectly fine, but game goes out of ds for a fraction of a second when releasing SUPER and the bar closes.

@Dregu Got a fix for this. Beforehand, any fadeouts whatsoever would block solitary (and thus DS), even ones on background or bottom which would never be above the FS window. Have sent patch to erstarr, will probably appear here soonish

Dregu · 2026-09-05T19:55:03Z

If you say so, I did specifically only test an invisible (i.e. opened before fullscreen) top layer on main though and its fadeout did not block DS.

And yes the protocol specifically says "order is undefined" so we can do whatever we want with FS, screw all the shells that assume top might go above FS.

LRitzdorf · 2026-09-05T20:29:41Z

an invisible (i.e. opened before fullscreen) top layer on main though and its fadeout did not block DS.

Huh, I just checked that specific case on main, and it did block DS:

Well, in any case, it's fixed on this branch now!

FakeMichau · 2026-09-09T11:55:43Z

Can confirm that this PR fixes the issue I was seeing in #15881.
But seems like allow_new_top_layers_over_existing_fullscreen has no effect. The fix seems to be always active regardless of the setting.

erstarr · 2026-09-12T21:54:38Z

Really busy nowadays and don't have the time for this. I'll get to this as soon as I can (prob on the 18th or that weekend)

…ync upon work area change (#16493) * change * test-preliminary * new helper function -- extracted from #15937 * test - complete

…sed and fullscreen

…allow_new_top_layers_over_existing_fullscreen = false was tested in the prev test commit

…handled test

…orrow. It probably won't come.

Fixes an issue where a fadeout (on *any* layer) would block solitary, and thus also DS, while in progress.

erstarr · 2026-10-17T18:12:26Z

@vaxerski poke

…ync upon work area change (hyprwm#16493) * change * test-preliminary * new helper function -- extracted from hyprwm#15937 * test - complete (cherry picked from commit 1bd31aa) [Hypoland: without the hyprtester and nix parts]

github-actions Bot added core desktop labels Aug 22, 2026

erstarr force-pushed the painAndSuffering branch from a5256a0 to 05b16d1 Compare August 22, 2026 05:38

erstarr marked this pull request as ready for review August 22, 2026 22:28

github-actions Bot requested a review from vaxerski August 22, 2026 22:28

github-actions Bot added the config label Aug 23, 2026

erstarr force-pushed the painAndSuffering branch from fad9e3c to bd0967a Compare August 23, 2026 17:04

erstarr marked this pull request as draft August 29, 2026 16:16

erstarr changed the title ~~core/layers: Top layers go below fullscreen windows~~ core/layers: Top layers go below fullscreen windows, fix DS solitary Sep 5, 2026

LRitzdorf mentioned this pull request Sep 8, 2026

[FEATURE] Set layer alpha when hiding statusbar noctalia-dev/noctalia#4348

Open

2 tasks done

erstarr force-pushed the painAndSuffering branch from 7400729 to 9905d35 Compare October 4, 2026 17:41

github-actions Bot added managers layout labels Oct 4, 2026

erstarr force-pushed the painAndSuffering branch 3 times, most recently from 13aba9c to 957bd57 Compare October 10, 2026 16:34

vaxerski pushed a commit that referenced this pull request Oct 13, 2026

fullscreen/scrolling: scrolling default handled fullscreen position s…

1bd31aa

…ync upon work area change (#16493) * change * test-preliminary * new helper function -- extracted from #15937 * test - complete

erstarr and others added 19 commits October 15, 2026 03:22

why do we suffer?

36053fe

begone

be4f861

format

b5cd1ae

TEST - Top and Overlay - spawn before and after FS - test both maximi…

72c87ac

…sed and fullscreen

add config opt

dc273b4

meow

d8b05b3

add TEST for allow_new_top_layers_over_existing_fullscreen = true -- …

1e6158c

…allow_new_top_layers_over_existing_fullscreen = false was tested in the prev test commit

fix default handled test, clone the def test into scrolling's layout …

4ce6b7d

…handled test

The whole thing is quite hopeless, so it's no good worrying about tom…

e605ff4

…orrow. It probably won't come.

whatDidIDoToDeserveThis

4c6aaee

monitor: only non-transparent overlay layers can block solitary

e767ebe

Fixes an issue where a fadeout (on *any* layer) would block solitary, and thus also DS, while in progress.

testFixAttempt

f799fc1

fix oopsie

8869c46

testFixAttempt2

ab590f4

whole lot of fixes and cleanups

ec42e17

fix scrolling's test

c806281

format

e8ebebd

redundant includes

3f76698

do not show a layer in hyprctl layers before it is mapped

39b414b

erstarr force-pushed the painAndSuffering branch from 957bd57 to 39b414b Compare October 15, 2026 01:24

erstarr changed the title ~~core/layers: Top layers go below fullscreen windows, fix DS solitary~~ core/layers: top layers go below fullscreen windows, fix DS solitary Oct 17, 2026

vaxerski reviewed Oct 19, 2026

View reviewed changes

Comment thread src/output/Monitor.cpp Outdated

review fix: value -> goal

00485cc

vaxerski approved these changes Oct 20, 2026

View reviewed changes

Conversation

erstarr commented Aug 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Describe your PR, what does it fix/add?

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

Is it ready for merging, or does it need work?

Uh oh!

vaxerski commented Aug 23, 2026

Uh oh!

erstarr commented Aug 23, 2026

Uh oh!

Dregu commented Aug 23, 2026

Uh oh!

LRitzdorf commented Aug 23, 2026

Uh oh!

darkwater commented Aug 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

erstarr commented Aug 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

erstarr commented Aug 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vaxerski commented Aug 26, 2026

Uh oh!

Dregu commented Sep 3, 2026

Uh oh!

erstarr commented Sep 3, 2026

Uh oh!

Dregu commented Sep 3, 2026

Uh oh!

LRitzdorf commented Sep 5, 2026

Uh oh!

LRitzdorf commented Sep 5, 2026

Uh oh!

Dregu commented Sep 5, 2026

Uh oh!

LRitzdorf commented Sep 5, 2026

Uh oh!

FakeMichau commented Sep 9, 2026

Uh oh!

erstarr commented Sep 12, 2026

Uh oh!

erstarr commented Oct 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

erstarr commented Aug 22, 2026 •

edited

Loading

darkwater commented Aug 23, 2026 •

edited

Loading

erstarr commented Aug 23, 2026 •

edited

Loading

erstarr commented Aug 23, 2026 •

edited

Loading

erstarr commented Oct 17, 2026 •

edited

Loading