Drakulix
commented
3 years ago Yeah, I have come to this conclusion as well.
Especially for the wayland-backend we are not only loosing a lot of information, but we need to abstract over winit, which abstracts over wayland-client, although we could pass through some protocols with minimal changes or atleast work with the protocol-native types instead of the winit ones.
For the new rendering api this would also very much be desirable, as we could just attach dmabufs via wayland-client without relying on wayland-egl or the eglsurface api and much more closely mimic the drm-backend.
I don't have a strong opinion about that though, given the winit backend is mostly intended for dev & debug, so release builds using smithay might want to have it disabled anyway, but I'm opening this issue for discussion around it.
Which is why I would still keep it. For quick testing the backend is totally fine and might even be useful for some experiments like running anvil on windows/macos. But it is not a proper nested compositor experience and should not be advertised as such.
i509VCB
I'm more and more starting to think this would be desirable, for mostly two reasons:
I don't have a strong opinion about that though, given the winit backend is mostly intended for dev & debug, so release builds using smithay might want to have it disabled anyway, but I'm opening this issue for discussion around it.
(It is definitely not a goal for the 0.3 release anyway)