Regarding the outputdevice Wayland protocol

[Martin Flöser]

Am 2017-11-07 09:03, schrieb Sebastian Kügler:
> Hi Drew,
> 
> Thanks for reaching out!
> 
> On zaterdag 4 november 2017 15:10:33 CET Drew DeVault wrote:
>> As part of our effort to reuse existing Wayland protocols for common
>> desktop features in Sway (and wlroots), we're taking a look at KDE's
>> output-management.xml. However, we feel like the related
>> outputdevice.xml protocol has some overlap with wl_output - can you
>> provide some context for these protocols and would you consider
>> working with us on a simplified protocol we can share?
> 
> outputdevice.xml is indeed an extended version of wl_output. It has
> some additional options that we need for the outputmanagement stuff, so
> it becomes useful, wl_output wasn't sufficient there. I've added the
> current mode, edid and enabled fields, as wl_outputs are always
> supposed to be enabled, and outputdevices are just connected displays
> which may be enabled or not. We also needed a way to pass through the
> edid blob. We've checked with upstream wayland, and there was "little
> desire" to have these things in wl_output, so an extended version is
> what we did. I'm not overly happy with this, but at some point we had
> to move on, even if it left warts on the protocol semantics.
> 
> A simplified protocol to be shared could be two things:
> 
> * merged wl_output with edid, currentmode and enablement added
> * simplified outputdevice which uses a wl_output and attaches just the
>   above properties
> 
> I'm not sure if the above *could* work, since a wl_output was never
> designed to be not enabled, so just sitting there, being available, but
> the above is at least what I can imagine recalling the discussions we
> had back then when we implemented it in kwayland. Martin can probably
> provide some more insight here.

Not much to add to what sebas writes. Only I can point out that I 
currently have an open review for the first addition:
the supported transformations on an output. The idea behind that is to 
tell KScreen what transformations it can offer to select. And thus the 
whole interface is designed for screen configuration tool. Given that I 
don't think it makes much sense to try to merge with wl_output.

So for sway the question is whether you want to have a screen 
configuration tool talking through Wayland with the compositor. If you 
don't need that you can probably just forget about this interface. If 
you need something like that it makes sense to reuse our protocols. We 
spend quite some engineering effort into it. I remember that we defined 
the protocols for weeks till we were happy with them.

Interesting side node: we had these protocols around for quite some 
time, but not hooked up in KWin. The last two weeks I worked on it and 
everything works exactly as we wanted from the start. No need to change 
anything in KScreen or the protocol. Everything just works after 
connecting the hooks.

Cheers
Martin