Modularize Smithay

[i509VCB]

At the moment smithay is a largely monotlihic api. As of writing this, smithay has 19 crate features.

This number is expected to continue to grow with just some of the following additions:

• Wayland backend
• Abstraction over X11 and Wayland backends
• Vulkan allocator
• Vulkan renderer
• Software renderer

Potentially reaching at minimum 24 crate features.

I feel the solution to our problem is to split smithay into multiple crates within the same repository.

Where to split

Some parts of smithay are entangled with others, these parts would need to be logically considered as one unit or untangled.

We do have a frontend and backend split that we could utilize.

I think we could consider splitting some of these features from the backend into individual crates since these are reasonably isolated:

• EGL
• Gles2 rendering
• winit, x11 and wayland backends
• Sessions
• Gbm

The frontend would largely need to be in the same crate due to tight integration. There could be some parts split out if needed.

XWayland helpers could be handled in its own crate (since it is optional).

Desktop seems like another great boundary to split off of. Desktop would nessecarily depend on some of the frontend and backend crates.

I imagine this will not happen immediately, especially given 0.30 is in progress, but it will be a good thing to consider long term.

[Drakulix]

While I agree with the general direction, I am not sure, that we could split smithay this easily.

For example the rendering + backend + allocator code is far too entangled in my opinion (while the Gles2-code is indeed mostly a clean implementation of this set of traits). The desktop code with the buffer-management helpers also bleeds into this part of the code base out of necessity.

Trying to separate all of this, I expect we will run into the orphan rule a lot. So it might be easier to just do a "smithay-backend"-crate for now and just split out some well contained parts like EGL or the Gles2-implementation.

[i509VCB]

Linking this for future discussion: https://matklad.github.io/2021/08/22/large-rust-workspaces.html