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