Consider having direct Wayland/X11 backends instead of winit

[elinorbgr]

I'm more and more starting to think this would be desirable, for mostly two reasons:

• winit hides a significant amount of low-level details that we would want for proper handling, meaning at this point I'm not 100% sure using winit does actually simply things that much
• winit forces significant dependencies duplications on us

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)

[Drakulix]

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]

#371 has been merged so the X11 side of the pond has been handled for this issue. A wayland backend is what is left for this issue.