Integration of wl_output support #26

New issue

Open

opened 2026-02-10 23:44:24 +01:00 by JoshStrobl · 0 comments

JoshStrobl commented

2026-02-10 23:44:24 +01:00

Owner

What that means in practice is to achieve panel placement on correct outputs, we need to at least start out with supporting just plain ol' wl_output. This supports an extremely limited set of output details, such as mode and geometry, but it should be enough for us.

This is effectively implemented already via KWayland, however we have our own logic for attempting to create stable serials for outputs, and this has proven to be successful thus far.

Therefore, the first phase of our work is integrating it into our MetaHead for "current" properties then wlr for supplemental. We will need to think up a good model for this that will enable us to more trivially extend to support other protocols in the future (e.g. create a class they all implement and provide signals for).

The second phase (not associated with this ticket) would then be subsequently splitting out all of that into its own library so it can be used (for read-only) in the panels (since we may not want to do it over DBus).

Right now we support just wlr_output_management and its related head and mode objects. Magpie (as in our Mir-based Magpie) will not support that protocol, rather it will initially just have wl_output and then down the likely support for KDE Output Management v2 (at least, that's the goal anyways). What that means in practice is to achieve panel placement on correct outputs, we need to at least start out with supporting just plain ol' wl_output. This supports an extremely limited set of output details, such as mode and geometry, but it should be enough for us. This is effectively implemented already via KWayland, however we have our own logic for attempting to create stable serials for outputs, and this has proven to be successful thus far. Therefore, the first phase of our work is integrating it into our MetaHead for "current" properties then wlr for supplemental. We will need to think up a good model for this that will enable us to more trivially extend to support other protocols in the future (e.g. create a class they all implement and provide signals for). The second phase (not associated with this ticket) would then be subsequently splitting out all of that into its own library so it can be used (for read-only) in the panels (since we _may_ not want to do it over DBus).