Compositor fragmentation - Discussion

[proton-decay]

@Drakulix, I have just recently noticed you are the developer of fireplace. I heard about fireplace but as it uses wcl and my goal was to write compositor from scratch in Rust I simply ignored it. Now that you work with @vberger on smithay we have the same goal. I would really like to see merge between perceptia and fireplace.

Have a look at architecture overview. If perceptia was turned into library, would it be feasible to use it in fireplace? Or maybe less effort would be to move pieces of fireplace into perceptia?

[Drakulix]

I am very excited about this idea, as I feel both projects could really benefit from this and gain a lot of momentum.

However the structure of both projects is currently really different.

fireplace uses a tree-like structure that splits and reroutes events from wlc to the smallest parts of the program, while perceptia seems to be build upon the notion of signals.

While I like the general idea of signals, I am not a big fan of them in most implementations, let me explain why. I feel, that it is very easy to forget to handle a signal in one of the many components, that are responsible of handling small subsets of the required actions, leaving the whole application in an inconsistent state. It also can generate a quite large dependency graph between the different modules, where every module starts depending on many different signals, connecting and interleaving parts of the program, that don't really belong together, which makes clean abstractions a lot harder. At least the first issue, is usually not a problem in rust, especially in a tree structure, because rust will warn you, if you don't use any variables (events in that case).

I have rewritten huge parts of fireplace in its initial development about 4 times until I was satisfied with the resulting structure...... but I feel quite a lot of this structure is bound to how wlc works, which is why I currently leave fireplace in low-maintenance-mode. I don't actively develop any new features for it anymore, as I feel, that large parts will be refactored once smithay is eventually usable.

As I result, I am neither happy with how perceptia is designed (with my current limited knowledge about this project) nor about the design of my very own project fireplace.

Additionally if we merge both efforts, I would really like to keep it compatible with both skylane and @vberger 's wayland libraries, just in case.

I also feel like an abstraction library sitting in between like smithay, that just abstracts devices,sessions,input and graphics backends and all that stuff away, would be very useful for a clean structure and allows other people to create alternatives to this project.

What I really don't want to build is another giant compositor like weston, gnome's mutter or kde's equivalent, that nobody else really understands. I want to build a solid foundation for everyone to build a wayland compositor, that I can base my own ideas and experiments upon.

I still think we have quite a similar goal here, I am just not sure, what exactly is the best way forward.

[proton-decay]

You should not be concerned about signals. They are only notifications about events and convey just basic parameters. There is small amount of signals (like "device found", "output found", "surface managed", "keyboard event") so when you want to be notified about something you won't forget to subscribe signal you need. There's also no worry about inconsistent state. The state that is common to all threads is surface metadata + info about currently focused surface (probably more in future) and it is shared between threads. But that does not matter.

With resulting library you don't have to use signals. You can take for example whole DeviceManager and let it do its job, or take only its constitutes like OutputCollector or VirtualTerminal and arrange them as you want or ignore everything and take only UDev which lets you only easily iterate over devices and do the rest your way. Similarly you can take whole Exhibitor and let it manage displays and surfaces or glue its constituent as you like maybe replacing RendereGl or alternating behavior of Compositor providing your own Strategist. You can also use only OutputDrm and InputManager and instead of compositor make your full-screen game.

Of course without signals you have to communicate everything with your own implementation, but I guess you already have it. And it's not available right now, but give me weekend or two and library is yours.

[Drakulix]

This all sounds very reasonable. Many of these components like DeviceManager and the Udev code however sounds a lot more, like they would better be moved into smithay instead of fireplace. And then rebuild fireplace onto the result of that merge.

Also how bound is perceptia currently to skylane? Would it be easy to support the wayland-crates additionally?

[proton-decay]

If you don't want to use skylane you simply provide alternative implementation of wayland_frontend and because you also want your own communication, then I suppose you are free to do anything.