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
