Architecture: split backends into input, output, and local parts
We have the screen-share plugin which uses some libweston internal APIs because it needs to deliver input events to the libweston core.
We have the remoting plugin and the pipewire plugin using the DRM-backend virtual output API and libweston internal API. The virtual output API exists only because libweston (the backends) cannot handle multiple kinds of outputs at the same time.
A proposition. Split the backend architecture into three pieces:
- Input backends deliver input to libweston core.
- Output backends implement outputs and call into renderers.
- Local backends (in lack of a better name) handle the local setup, e.g. VT setup.
The point here is that one could have more than one input backend or output backend active at the same time. Local backends can only be active one at a time, since they manage singular things like the active VT.
E.g. the DRM-backend would be all three.
Then screen-share plugin could act as an additional input backend, the remoting plugin and pipewire plugins could act as additional output backends, and the need for DRM-backend virtual output API would disappear. This means that these plugins could be used with any old backend.
Furthermore, e.g. the RDP-backend could be turned into a combined input/output backend that could be loaded in addition to e.g. the DRM-backend. That would make the screen-share plugin obsolete.
Things like weston_seat, weston_head and weston_output would need to be dynamically typed, so that backends only touch their own bits.
Just a rough idea, not really thought through. I'm not sure if this goes too far, or what the split would actually look like in code: probably it would happen at API level, and not splitting modules into more modules, but there would be some provision to load together modules that are not possible today.
This would probably take a good few months to design. The primary aim would be to allow additional inputs and outputs.