fullscreen global: black screen after update to 1.10

[532910]

after update to 1.10 (debian-experimental) fullscreen global just shows black screen, even with only one monitor

[rod-stuchi]

In my case (running on Arch, 6.11.5-arch1-1), Sway 1.10

when I try to put some application on fullscreen $mod+f the mouse cursor locks and nothing else happens

[532910]

simple fullscreen works fine for me:

bindsym --to-code $mod+a fullscreen global
bindsym --to-code $mod+Shift+a fullscreen

[rod-stuchi]

global fullscreen is working for me, only problem with simple fullscreen

bindsym --to-code $mod+f fullscreen global
bindsym --to-code $mod+Shift+f fullscreen

[532910]

when I try to put some application on fullscreen $mod+f the mouse cursor locks and nothing else happens

bindsym --to-code $mod+f fullscreen global

so mod+f is a fullscreen global in your case

[rod-stuchi]

when I try to put some application on fullscreen $mod+f the mouse cursor locks and nothing else happens

bindsym --to-code $mod+f fullscreen global

so mod+f is a fullscreen global in your case

Nope, I just copied your keybindings and changed to f instead of a to test.

tried with swaymsg 'fullscreen enable' in a terminal (wezterm), same issue

[egnappahz]

I have the same problem. I got 3 screens so global full screen is not a valid workaround for me. I fullscreen per monitor(workspace).
I got more additional confusing info!
On some specific screens when applications go fullscreen by accident (when it spans accross the entire screenarea), that application freezes aswel. These weird freezes happens on 2 of my 3 screens, not my "main" one, although I dont think wayland even has the concept "main screen" (EDIT: must be a workspace1 thing then I guess?). When I am able to resize/move the application so they dont span across the entire area of the screen, the freezing of the app stops.
But I must admit, I have different GPUs driving different monitors, so I have too many moving parts here to give a clear assesment.

EDIT:
This isnt because of the new "tearing-control-v1" right? I'm just guessing here.

Graphics APIs like EGL or Vulkan, that manage the buffer queue and commits of a wl_surface themselves,
are likely to be using this extension internally.
If a client is using such an API for a wl_surface,
it should not directly use this extension on that surface,
to avoid raising a tearing_control_exists protocol error.

[benjamineeckh]

Same problem over here (black background), nothing changed just upgraded to v1.10. It also does not respect my window layout anymore, they are suddenly swapped (ie. 1|2 became 2|1).
I am also using "fullscreen" for the fullscreen toggle. (bindsym $mod+f fullscreen)

Also locks up graphically when fullscreening a window. But only graphically, my system is still responsive, just the display where the pdf was openened does not update anymore.
I can also just focus the display and close the pdf/un-fullscreen it, after which the glitch is gone.

Running on 6.11.5-arch1-1

[Nefsen402]

Could anyone affected by this collect logs? (run sway with -d and post the output of stdout) It seems there is an issue with direct scanout not bailing correctly.

[egnappahz]

Here are my repeating relevant errors when a freeze occurs:

00:00:13.454 [ERROR] [wlr] [backend/drm/renderer.c:88] Failed to import source buffer into multi-GPU renderer
00:00:13.454 [ERROR] [sway/desktop/output.c:317] Page-flip failed on output HDMI-A-2
00:00:13.454 [ERROR] [wlr] [backend/drm/renderer.c:88] Failed to import source buffer into multi-GPU renderer
00:00:13.454 [ERROR] [sway/desktop/output.c:317] Page-flip failed on output HDMI-A-2
00:00:13.455 [ERROR] [wlr] [backend/drm/renderer.c:88] Failed to import source buffer into multi-GPU renderer
00:00:13.455 [ERROR] [sway/desktop/output.c:317] Page-flip failed on output HDMI-A-2
00:00:13.455 [ERROR] [wlr] [backend/drm/renderer.c:88] Failed to import source buffer into multi-GPU renderer
00:00:13.455 [ERROR] [sway/desktop/output.c:317] Page-flip failed on output HDMI-A-2
...

[532910]

00:00:24.628 [DEBUG] [sway/commands/bind.c:618] running command for binding: fullscreen global
00:00:24.628 [INFO] [sway/commands.c:261] Handling command 'fullscreen global'
00:00:24.628 [DEBUG] [sway/desktop/transaction.c:798] Transaction 0x55b8f136ef10 committing with 1 instructions
00:00:24.728 [DEBUG] [sway/desktop/transaction.c:884] Transaction 0x55b8f136ef10 is ready
00:00:24.728 [DEBUG] [sway/desktop/transaction.c:694] Applying transaction 0x55b8f136ef10
00:00:24.729 [DEBUG] [sway/input/cursor.c:888] denying request to set cursor from unfocused client

[532910]

this issue is about fullscreen global not about fullscreen
please open another issues for fullscreen without global

[egnappahz]

I seriously doubt that.

[egnappahz]

For me adding the variable

WLR_SCENE_DISABLE_DIRECT_SCANOUT=1

was a good enough workaround, I see what you mean now @Nefsen402

[532910]

1. WLR_SCENE_DISABLE_DIRECT_SCANOUT=1 changes nothing
2. fullscreen without global works as expected
3. I have no errors in the debug log

Please stop mixing different issues into a single one.

[egnappahz]

You are right, you have another problem.
But freezes were mentioned here. Left it out there for people with a similar problem so they can have a better understanding what is what, because maybe everything is crystal clear to you, it was not to me.

[emersion]

Can you post a full debug log please? Not just a snippet?