<div dir="ltr"><div>Hi<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 29, 2019 at 9:05 AM Simon Ser <<a href="mailto:contact@emersion.fr">contact@emersion.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Monday, April 29, 2019 9:51 AM, Olivier Fourdan <<a href="mailto:ofourdan@redhat.com" target="_blank">ofourdan@redhat.com</a>> wrote:<br>> > On Sunday, April 28, 2019 12:04 PM, Olivier Fourdan <<a href="mailto:ofourdan@redhat.com" target="_blank">ofourdan@redhat.com</a>> wrote:<br>
> IMHO, it would better, semantically, to keep `xdg-output.done` and<br>
> clarify (in xdg-output) that the `xdg-output.done` event is sent once<br>
> all properties on wl_output _and_ xdg-output are set, xdg-output<br>
> being a superset of wl_output. This way we would keep things apart<br>
> but also still guarantee atomicity.<br>
<br>
What if we have another protocol that extends wl_output? How can you<br>
atomically send xdg_output state and the other protocol's state?<br>
<br>
This solution doesn't scale.<br></blockquote><div><br></div><div>Humm, that's a good point.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

> Besides, that would be easier on the existing clients that would<br>
> (still) expect the `xdg-output.done` event and compositors that<br>
> wouldn't need to emit the event based on the protocol version used by<br>
> the client.<br>
<br>
That's a good point. I still think it's worth it to properly fix this<br>
issue.<br></blockquote><div><br></div><div>Then we have no choice but bumping the protocol version to differentiate those client which expect the xdg-output.done from those who won't.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> > [...]<br>
> > GNOME also doesn't expose all output properties IIRC: the whole list of<br>
> > output modes is not sent.<br>
><br>
> It does, mutter sends the full list of outputs with their size, scale<br>
> and position and gtk+ relies on it for its GdkMonitor, although there<br>
> are plans to move gtk to use xdg-output as well for its GdkMonitor<br>
> definitions.<br>
<br>
The whole list of outputs is sent, however the whole list of output<br>
*modes* isn't. Only the current mode is sent.<br>
<br>
I don't think GTK+ should rely on output positions, modes or logical<br>
geometry.<br></blockquote><div><br></div><div>gtk itself doesn't rely on it, but exposes it via its GdkMonitor API and gtk based applications (such as Firefox) may use it.<br></div><div><br></div><div>Cheers,</div><div>Olivier<br></div><div><br></div></div></div>