swc does not support subsurfaces

[ghost]

On command:

# mpv -vo wayland 1.mkv

Writes:

Playing: 1.mkv
[stream] Video (+) --vid=1 (h264)
[stream] Audio (+) --aid=1 (*) (aac)
Segmentation fault

I tried to gdb it and figured out that mpv requires that wl_keyboard_send_keymap must me called before wl_keyboard_send_modifiers. Because it saves state at wl_keyboard_send_keymap and uses it at wl_keyboard_send_modifiers.

On Weston mpv works fine.

[ghost]

I made commit that fixes this issue. It is in pull request #24.
The problem with handle_modifiers of mpv was fixed.

But mpv uses subsurfaces. I didn’t find subsurfaces support in swc.

[ianbeyst]

This is more than four years old and probably a different cause, but I'm still getting segfault when running mpv. In attachment is backtrace output, segfault occurs in wl_egl_window_resize () from /lib/libwayland-egl.so.1. Is this still the lack of subsurface support?
I'm running on void linux x86_64-musl.

gdb.txt

[michaelforney]

I'm not sure, the lack of debug symbols in the backtrace makes it difficult to tell? Perhaps the error happened earlier on, but was not caught due to lack of error checking in

https://github.com/mpv-player/mpv/blob/fbe267150d9b6a2486a73c13d58b2b24d69b50ad/video/out/opengl/context_wayland.c#L91-L105

Perhaps you could add some printf debugging there to figure out what's going on? I will see if I can reproduce (normally I use SHM mpv output, which works for me).

[michaelforney]

I managed to reproduce the mpv issue. It is the same issue I fixed 5 years ago in vo_opengl mpv-player/mpv@618361c that has resurfaced in vo_gpu.

The following diff to mpv should fix it. I'll open a pull request.

diff --git a/video/out/opengl/context_wayland.c b/video/out/opengl/context_wayland.c
index 650072c73c..8239f2101a 100644
--- a/video/out/opengl/context_wayland.c
+++ b/video/out/opengl/context_wayland.c
@@ -45,7 +45,8 @@ static void resize(struct ra_ctx *ctx)
     const int32_t height = wl->scaling*mp_rect_h(wl->geometry);
 
     wl_surface_set_buffer_scale(wl->surface, wl->scaling);
-    wl_egl_window_resize(p->egl_window, width, height, 0, 0);
+    if (p->egl_window)
+        wl_egl_window_resize(p->egl_window, width, height, 0, 0);
 
     wl->vo->dwidth  = width;
     wl->vo->dheight = height;

[ianbeyst]

Thanks! That indeed fixes the problem.
Do you have any picture in your head on what it would take to implement subsurface support? I'm not at all familiar with any of this and there is a terrible dearth of material to be found online but maybe if you point my eyes in the right direction I can contribute something. I would be really happy if firefox would work, as this is pretty much all that remains to reach feature parity with my X/dwm setup I'm on currently.

[michaelforney]

I don't have a full picture, but I did look at this a while ago and have some WIP changes that maybe you could start from. Let me see if they still apply, and then I'll push a branch.

I'd also be quite happy to get firefox to work, and having someone else interested in helping out might be enough motivation to finally get it done :)

[MichaelMackus]

👍 for subsurfaces. I think this is one of the main features stopping me from using velox as my daily. Any info you can give on what is needed from swc for this would be great - I can contribute any code that would be helpful. I'm still learning the wayland protocol but will have to lookup subsurfaces.

[michaelforney]

Thanks for your interest. To get the necessary background, read through https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_subsurface.

Basically, a subsurface is just a regular surface that should be moved, hidden, and shown relative to a parent surface, and the surface and all its subsurfaces are adjacent in the z-order.

There is some additional complexity in that a subsurface has two modes, synced, and desynced. In desynced mode, commits behave just like it were a normal surface. In synced mode, a commit to the subsurface stages its state which only gets applied upon a commit to the parent surface.

The main difficulties that came up when I looked at this were dealing with a tree of surfaces, since the compositor currently uses a linear list. It might be possible to keep the invariant that any subsurfaces come immediately after the surface in the compositor's surface list.