Wayland backend questions/notes/issues

[PolyMeilex]

Hi! I've been trying to use druid for my Wayland related project, but have encountered some unusual things in the wayland implementation.

Rendering

It's better to just show it instead of describing it, so here is the video of window resizing, it looks like there is something wrong in double buffering implementation, or perhaps xdg configure is somehow handled against the spec:

druid-rendering.webm

Handling of protocol versions

Addressed by: #2254
The choice of versions seems completely random and not based on any requirements, lack of certain version is not handled either.

Examples

• Druid does not run on Weston (reference implementation of wayland) because it tries to bind xdg_wm_base version 2, version 2 of xdg-shell introduced tiled_top/left/right/bottom states, but druid does not use them at all as far as I can tell, so why does it require it?
• Druid does not work on Mutter (Gnome's compositor) because it ignores any wl_seat versions lower than 7 also for no apparent reason (my memory is rusty but as far as I remember version 7 was mostly server side change that adds extra requirement for clients to map keymap file with MAP_PRIVATE, so I'm not sure why druid cares enough to straight up refuse to run on older versions)

Potential solution

Either we bind the lowest possible and carefully chooses version, or we have to handle multiple versions properly.
For example In sctk we simply define latest supported version and bind whatever meets 1..=max_version requirement. After that, any calls to newer methods are guarded by obj.version() >= n

## Handling of non-core protocols
I'm pretty sure that this is fixed by #2127, but I'll describe it anyway.
Druid does not run on Weston and Mutter because it tires to bind optional protocols like xdg decoration and layer shell, (layer shell is still in the process of standardization in Wayland).
It's cool to use non-core protocols, or event protocols not standardized in Wayland like layer shell, but all usage of those has to be behind Option<T> we can't just assume that it is available everywhere.

---

Side question: Why not Smithay client toolkit?

While reading the code, I see a lot of reinventing the wheel, most of the stuff that is not implemented, partially implemented or broken in druid is available in Smithay client toolkit and was since the early beginnings of wayland-rs. Was it considered? If so, what was the deciding factor to not use it, is there anything I can do to make it more suitable? It was designed to be modular and not take control away from the user, so I was pretty sure that druid will use it, the same way winit does, so I was surprised to find out that it does not. Would love to hear some feedback.

[james-lawrence]

rendering: def looks like something with the buffer management and resize. I didn't spend much time dealing with top level surfaces. they were not relevant to my use-cases; I'm not surprised there are issues there.

protocol versions: its probably a ~8 line fix version ranges; search for instantiate_exact and replace with instantiate_range. but untested; might be worth your time to just try it out and see if it resolves your problems.

smithay toolkit: no idea what state that is in now. I did actually look at it as a path sometime late last year. decided it wasn't worth the effort to convert to it given the state of it at the time and my usecases and personal effort involved. nothing against it personally it just wasn't ready at the time. I don't think anyone would be opposed to using it if it if someone is happy to do the lifting.

[PolyMeilex]

protocol versions: its probably a ~8 line fix version ranges; search for instantiate_exact and replace with instantiate_range. but untested; might be worth your time to just try it out and see if it resolves your problems.

It does resolve my problems both with weston and mutter, was just making sure that there is no particular reason for this behavior, but it sounds like there is none, so I'll take care of that and add version guards wherever needed 👍

I don't think anyone would be opposed to using it, if someone is happy to do the lifting.

Sounds good, now is probably not the best time as wayland-rs 0.30 update is still in progress across the whole stack, but once the dust settles I'll revisit the idea.

[james-lawrence]

@PolyMeilex this issue has a long conversation about druid and wayland support. if you havent seen it; then might be worth your time to read. esp giving your interest in the CSD vs SSD issues from the other thread.

fundamentally I think there is core internal refactoring druid needs to do to support CSD/SSD (and wayland in general) that you should probably be aware of. for me the issues in that thread are the big blockers for good wayland support long term.

[PolyMeilex]

Thanks!
I mainly want to target layer shell, or private equivalent (not sure yet), so CSD/SSD is not really in the set of my main interests, but I'm trying to polish the toplevel backend as well as a side quest, so I'll take a look.