<table><tr><td style="">romangg added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D29028">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D29028#654542" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D29028#654542</a>, <a href="https://phabricator.kde.org/p/davidedmundson/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@davidedmundson</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>A new dependency also needs to actually solve an actual problem.</p>

<p>If we say we should support wl_roots' protocol for wlroots users. Fair enough. There are some parts of Plasma used by 3rd parties. <br />
 I'd certainly be very happy for us both to switch to a new standard given they're upstreaming some stuff currently.</p>

<p>But we then have to answer the technical question of why does that require a library with a different implementation of ConnectionThread/Registry and every client protocol in order to do so? Compared to using one technology throughout. Otherwise you're not really solving the original problem of having it available to users.</p></div>
</blockquote>

<p>For wlroots I have done in Wrapland a quick protocol implementation in two or three days. I have not done much testing and hope for more data from first use cases in the future to iterate it. Since KWayland is API/ABI-stable that won't be possible there. When at some point the implementation has become well tested why not copy-paste it too KWayland?</p>

<p>But this is not only about support for the wlroots protocol. In Wrapland I have rewritten KWayland's <a href="https://cgit.kde.org/kwayland.git/tree/src/client/protocols/outputdevice.xml" class="remarkup-link" target="_blank" rel="noreferrer">org_kde_kwin_outputdevice</a> protocol as <a href="https://gitlab.com/kwinft/wrapland/-/blob/e623d28af045083dc7c02edfa77c45477275b26d/src/client/protocols/kwinft-output-device-unstable-v1.xml" class="remarkup-link" target="_blank" rel="noreferrer">kwinft_output_device_unstable_v1</a>. It is mostly the same but I cleaned up some stuff, used semantics as it is standard nowadays and replaced the scale factor with a new way of defining the logical size of an output (basically <a href="https://phabricator.kde.org/D26311" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D26311</a>). So for libkscreen to work with KWinFT it needs to support this protocol. And I assume it isn't something that should go into KWayland. For API/ABI reasons again and because it already has one protocol, even if it's sub-optimal nowadays.</p>

<p>Of course when the protocol is stabilized and shows its merit it can always go into KWayland or whatever KDE Framework there will be in the future. Or we go for a common protocol with wlroots. I talked with Simon some time ago about their protocol and they have a mechanism with custom modes, but I find defining the logical size better. But I might be wrong on that and the kwinft_output_device_unstable_v1 protocol will tell me so in the future</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R110 KScreen Library</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D29028">https://phabricator.kde.org/D29028</a></div></div><br /><div><strong>To: </strong>romangg, Plasma, davidedmundson, apol<br /><strong>Cc: </strong>anthonyfieroni, tcanabrava, apol, davidedmundson, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, ahiemstra, mart<br /></div>