backend: set_max_buffer_size/set_default_max_buffer_size methods, on rs backend and libwayland 1.23+

[ids1024]

Adds a test and rs backend implementation for the function added in #815, based on top of #851.

I still want to add bindings (and rs impls) corresponding to wl_display_set_max_buffer_size and wl_client_set_max_buffer_size, but that shouldn't be hard. The main thing is adding support to the rs backend, and verifying consistent behavior.

We'll need add rounding to the rs backend like get_max_size_bits_for_size in libwayland. Maybe it would be best to use NonZeroUsize in the server and Option<NonZeroUsize> in the client, to express that unbounded buffering is an option, but only in the client...

[ids1024]

Hm, I though it was safe to rely on https://gitlab.freedesktop.org/wayland/wayland/-/commit/d074d52902633d8700ce06b484508db0f8fba02b, since the commit is dated 2021, but it was only merged in 2024.

So like #735, we probably want to use Smithay/dlib#22.

[CoffeeImpliesCode]

is there any way I can help with this? (as mostly an outsider, although I have some Rust experience)

[ids1024]

If anyone has an idea why the CI for #851 is hanging or how to reproduce it locally (or a better way to implement the test) that would be helpful, though probably not an easy thing to help with for anyone not already familiar with the internals of wayland-rs.

The other thing is what we want to do with the fact this requires a new libwayland version.

• Adding a feature flag will require a dlib replace with Allow attributes in macro invocations  dlib#22 (ping @elinorbgr)
  • Though that's a little annoying since without the client_system/server_system feature flag, we don't need a particular libwayland version, since it will use the rs.
    • For instance cosmic-comp has client_system but not server_system, and we probably want to be able to use this in the server code without a dependency on a new libwayland for the client code?
    • We can't really make the methods available if any(not(feature = "server_system"), feature = "wayland_version_whatever") since that isn't additive, as feature flags should be

Otherwise I don't really need help with some of the smaller things that need to be added here; I can just do those if these questions can be worked out, and those shouldn't take too long...

Edit: Oh, and wayland-client/wayland-server can't know if client_system/client_server are enabled in wayland-backend anyway.

[CoffeeImpliesCode]

It seems like @elinorbgr has left GitHub in 2024 though?

[olafmustafar]

@ids1024 Is there any way to continue developing this project without relying on dlib (maybe by forking or incorporating it)? As mentioned, @elinorbgr seems to have been inactive for some time now, so the project seems unmaintained.

[ids1024]

dlib has been transferred to the smithay Github org now, so that it should be possible to get dlib released soon. So that won't block things, anyway.

[ids1024]

I've released https://crates.io/crates/dlib/0.5.3, and I think I have a solution for how for to deal with libwayland version feature flags (used in #873), although there's not a perfect way to handle that and the two backends.

So this should be unblocked now.

[ids1024]

Adding a feature flag and testing on CI with an older and newer libwayland version seems to work.