GTK4 and ext-session-lock-v1

[happenslol]

Hi everyone!

I'm looking to implement a screen locker with the ext-session-lock-v1 protocol using GTK4, and I thought this might be a good place to get some help since this project also had to work around the fact that custom surface support was removed.

The session lock protocol requires the user to pass a surface for each screen, which will be exclusively displayed on that screen. In GTK3, that was possible like this (in rust):

let wl_window = gtk_window.downcast::<gdkwayland::WaylandWindow>().unwrap();
gdk_wayland_sys::gdk_wayland_window_set_use_custom_surface(wl_window.to_glib_none().0);
let wl_surface = get_wl_surface(&wl_window); // omitted helper function
session_lock.create_lock_surface(surface, &output, &queue_handle);

Since gdk_wayland_window_set_use_custom_surface has been removed in GTK4, I've had a look at the code to figure out what it actually does. The only 2 places that are affected by the use_custom_surface flag in GTK3.24 are window mapping (which is aborted early if the flag is set) and should_inhibit_size (which is always FALSE if the flag is set). I feel like it should somehow be possible to prevent these 2 things in GTK4 as well.

It seems from reading the discussions on the gtk3 repo for this library that a lot of the difficulty with porting this library came from the fact that

1. GTK4 creates an XDG surface automatically, which needs to be prevented, and
2. Popups are difficult to handle (not sure if I understood this correctly).

2 is definitely not a problem, since the session lock protocol only allows one surface per screen, which rules out popups in general. I haven't tested yet if the wayland client libraries are fine with receiving an XDG surface, I'll do that later today.

Does anyone have any thoughts on how this could work? Could techniques from this library be used to help me? Are there other effects of use_custom_surface that I've missed?

[wmww]

EDIT: proper session lock support has now landed in main, and will be released shortly

Hi! Seems like you're on the right track. The main issue with using the session lock protocol with GTK is indeed stopping GTK from creating an XDG shell surface. I strongly suggest using the approach this library does, as explained here and mostly implemented here.

Since ext-session-lock-v1 is a well established and useful protocol, I'd consider adding support for it to this library. Not sure if I'll get around to it any time soon, but PRs absolutely welcome.

[happenslol]

Alright, I understand. I'm not sure I even need the protocol to be implemented in this library - the interaction with the protocol itself is handled by smithay's client toolkit as seen in this example, and I can already access the surface as is in gtk4.

I'll try to see if it's possible to use this library to only replicate the effects of use_custom_surface. Happy about any pointers or tips!

[happenslol]

Ended up just going for the complete implementation in this repository. I think I'm pretty close, but there's some issues due to the fact that the order of operations is different for the session lock protocol. the layer shell protocol states the following:

Creating a layer surface from a wl_surface which has a buffer attached or committed is a client error, and any attempts by a client to attach or manipulate a buffer prior to the first layer_surface.configure call must also be treated as errors.

After creating a layer_surface object and setting it up, the client must perform an initial commit without any buffer attached. The compositor will reply with a layer_surface.configure event. The client must acknowledge it and is then allowed to attach a buffer to map the surface.

While the session lock protocol states:

The client is expected to create lock surfaces for all outputs currently present and any new outputs as they are advertised. These won't be displayed by the compositor unless the lock is successful and the locked event is sent.

Providing a wl_surface which already has a role or already has a buffer attached or committed is a protocol error, as is attaching/committing a buffer before the first ext_session_lock_surface_v1.configure event.

Doing the exact same as the layer protocol doesn't seem to work, and I suspect that's because we need to wait for the configure event before attempting to map the windows. Otherwise the commit will happen, which is a protocol error. I'm unsure whether to require the library consumer to do this, or require them to just pass all control flow to the library for showing the windows... I'll try and see which feels better.

[happenslol]

Ok jesus christ, I think I've actually done it. I'm not used to writing C/Glib all that much so my code probably needs a whole lot of cleanup. I'll open a PR and I'd be happy about any feedback whenever you get around to it :-)

[wmww]

Nice work! I've been doing some major refactors of the library in order to make implementing additional protocols like this easier and also use it with more than just GTK. Please open a PR with whatever you've got if it works. Instead of merging it I may use it as reference for writing a session lock implementation against the updated libwayland_shim API, but it would be nice to have either way.

[happenslol]

Done!