support wlr-output-management-unstable-v1?

[KiaraGrouwstra]

the wlr-output-management-unstable-v1 protocol "exposes interfaces to obtain and modify output device configuration".
this is used by tools such as kanshi.

[YaLTeR]

How should it work with niri's config live reload? I.e. if you change the output config in niri then it will apply it; what happens if you're also running some wlr-output-management program?

[KiaraGrouwstra]

fair question! i imagine users might prefer such state get retained somehow. that said, i acknowledge the technical challenge there, and believe even without a way to retain such state supporting this would already make for an improvement.

[Supreeeme]

I believe in the case of sway, the config just overrides whatever the program does. That seems reasonable and simple enough to me.

[morenathan]

Why not just drop the config and have niri do A "best effort" if there is not a manager?

I myself recently ran into the problem where my displayport numbering was changing each reboot. With the way niri is now you're constantly updating the config and it is annoying!

The problem has since been fixed with all monitors on a single MST chain.

What would be interesting would be if niri supported monitor groupings in the config. So if monitors x y we're present. It would be one config. Whereas, if monitors x y z were present then it would be another config.

EDIT; I was just thinking if you did support this standard it could be linked to a command, or a simple niri monitor configuration.

[YaLTeR]

I myself recently ran into the problem where my displayport numbering was changing each reboot. With the way niri is now you're constantly updating the config and it is annoying!

When Smithay switches to libdisplay-info for EDID parsing, we will be able to use monitor model, name, etc. and not just connector name for matching. This should help here.

Plus, 0.1.6 added niri msg output so you can use that in some cases instead of editing the config.

What would be interesting would be if niri supported monitor groupings in the config. So if monitors x y we're present. It would be one config. Whereas, if monitors x y z were present then it would be another config.

Maybe; but also maybe with wlr-output-management this could be delegated well enough to existing tools.

[YaLTeR]

Made an issue here: #370