<div dir="ltr"><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 9, 2016 at 8:18 PM, Jonas Ådahl <span dir="ltr"><<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Fri, Apr 29, 2016 at 12:37:22PM +0300, Pekka Paalanen wrote:<br>
> On Fri, 29 Apr 2016 15:31:28 +0800<br>
> Jonas Ådahl <<a href="mailto:jadahl@gmail.com">jadahl@gmail.com</a>> wrote:<br>
><br>
> > On Thu, Apr 28, 2016 at 02:08:07PM +0300, Pekka Paalanen wrote:<br>
> > > On Thu, 28 Apr 2016 17:36:58 +0800<br>
> > > Jonas Ådahl <<a href="mailto:jadahl@gmail.com">jadahl@gmail.com</a>> wrote:<br>
> > ><br>
> > > > On Thu, Apr 28, 2016 at 10:36:14AM +0200, Martin Graesslin wrote:<br>
> > > > > Hi Wayland and Plasma,<br>
> > > > ><br>
> > > > > I finished the implementation of xdg-shell in KWayland [1] and KWin [2].<br>
> > > > > Overall it was more straight forward than I would have expected. Especially<br>
> > > > > the changes to KWin were surprisingly minor (with one huge exception).<br>
> > > > ><br>
> > > > > Now some questions/remarks:<br>
> > ><br>
> > > > > * Why is the ping on the shell and not on the surface? I would have expected<br>
> > > > > to ping the surface. At least that's how I would want to do it from KWin.<br>
> > > ><br>
> > > > Because you don't ping a surface, you ping the client. It's the client<br>
> > > > that may be inresponsive, and if the client is in responsive, it's safe<br>
> > > > to assume all its surfaces are as well.<br>
> > ><br>
> > > Hi,<br>
> > ><br>
> > > I was going to plain agree and say, that all events to a client come<br>
> > > through the same connection (wl_display), and it does not make sense to<br>
> > > have a series of ping events on different objects when they could just<br>
> > > be collapsed into one equivalent event.<br>
> > ><br>
> > > But then I thought about multiple client-side event queues. If a client<br>
> > > has multiple queues, and windows on different queues, it could be<br>
> > > possible that only some queues get stuck while others are serviced.<br>
> > > With per-surface pings, the compositor should then "shade out" only the<br>
> > > windows where the queue is actually stuck.<br>
> > ><br>
> > > Would it be worth it?<br>
> ><br>
> > I doubt it. What would you do? It's not like you can disconnect half of<br>
> > a client.<br>
><br>
> Wasn't it more about marking unresponsive surfaces and providing UI<br>
> aids for dealing with them, e.g. moving the window out of the way?<br>
><br>
> If you hover over the "kill this app" option, the compositor could e.g.<br>
> color all the surfaces that would go, not just the ones unresponsive.<br>
><br>
> > ><br>
> > > Or, is there an underlying assumption that a client might not send pong<br>
> > > requests as a simple reaction to ping events directly, but delay or<br>
> > > delegate it to some mechanism responsible for other updates?<br>
> > ><br>
> > > That is, is the ping-pong protocol a keep-alive for the Wayland<br>
> > > connection, for client's event queues, or something deeper in the<br>
> > > client?<br>
> ><br>
> > My understanding of the ping-pong protocol is to make it possible for<br>
> > the compositor to know when a client has frozen so that it can get rid<br>
> > of it (ala "Force Quit").<br>
><br>
> Yeah, that's the final action, but there could be some less drastic<br>
> options too.<br>
><br>
> > > > ><br>
> > > > > The biggest problem for me is the request set_window_geometry. I think I<br>
> > > > > mentioned it already before on the wayland list. Basically I have no idea how<br>
> > > > > to implement that in KWin. We have only one geometry for a window and that's<br>
> > > > > mapped to the size of the surface/x11 pixmap. This geometry is used all over<br>
> > > > > the place, for positioning, for resizing and for rendering. I cannot add<br>
> > > > > support for this without either breaking code or having to introduce a new<br>
> > > > > internal API. That's lots of work with high potential for breakage :-(<br>
> > ><br>
> > > Have you looked at what you need to do to support windows that are<br>
> > > built from non-overlapping sub-surfaces, like what Jonas describes below?<br>
> > ><br>
> > > I suspect you might end up having to do that major internal API work<br>
> > > anyway by the sounds of it. A window may be a collection of surfaces,<br>
> > > not just one.<br>
> > ><br>
> > > How do you do the window geometry with server-side decorations? Why is<br>
> > > using only a part of client surface so different from using a<br>
> > > combination of client and server-only surfaces?<br>
> > ><br>
> > > > ><br>
> > > > > From the description it seems to be only relevant for shadows. Could we make<br>
> > > > > shadows an optional part in xdg-shell? That the server can announce that it<br>
> > > > > supports shadows in the surface?<br>
> > > ><br>
> > > > It's not only about shadow. Let me explain a scenario where a window<br>
> > > > geometry is needed, even when there is a mode where no shadow is drawn<br>
> > > > by the client.<br>
> > > ><br>
> > > > Consider we have the following window:<br>
> > > ><br>
> > > ><br>
> > > > +-------------------------------------------+<br>
> > > > | A window X |<br>
> > > > +-------------------------------------------+<br>
> > > > | |<br>
> > > > | /\ |<br>
> > > > | / \ |<br>
> > > > | / \ |<br>
> > > > | / \ |<br>
> > > > | /________\ |<br>
> > > > | |<br>
> > > > | |<br>
> > > > +-------------------------------------------+<br>
> > > ><br>
> > > > It can be split into two logical rectangles/areas: the window title, and<br>
> > > > the main content. This window may be consisting of two separate<br>
> > > > non-overlapping surfaces, for example one GLES surface, and one SHM<br>
> > > > surface. Only one of these surfaces will be the "window", while the<br>
> > > > other will be a subsurface.<br>
> > > ><br>
> > > > xdg_surface.set_window_geometry would here be used to describe, in<br>
> > > > relation to whatever surface was gets to act as "window", what the<br>
> > > > window geometry would be.<br>
> > > ><br>
> > > > ><br>
> > > > > Also I'm not quite sure about that, but it looks to me like QtWayland thinks<br>
> > > > > that the set_window_geometry is the geometry of the client-side-decoration,<br>
> > > > > while on GTK it looked to me like being the size of the shadow. Either I did<br>
> > > > > not understand that correctly, or our toolkits are not compatible.<br>
> > > ><br>
> > > > Not sure what you mean here. The window geometry is the geometry of the<br>
> > > > window (main content, window frame, window title etc) excluding the<br>
> > > > shadow, in relation to the surface used to create the xdg_surface.<br>
> > > ><br>
> > > > So if you have a surface which is 800x600, and shadow is 10 wide on all<br>
> > > > edges, then you'd have a window geometry which is x: 10, y: 10, width:<br>
> > > > 780, height: 580.<br>
> > > ><br>
> > > > ><br>
> > > > > At the moment I haven't implemented this request yet in KWayland as I would<br>
> > > > > not be able to use it in KWin anyway.<br>
> > > > ><br>
> > > > > As a note: if it's just about shadow for us in Plasma that's a rather useless<br>
> > > > > request. We already have a Wayland shadow implementation which allows us to<br>
> > > > > have the shadow outside the surface.<br>
> > > ><br>
> > > > So, what you are saying is that you want to change the xdg_shell to only<br>
> > > > guarantee support for hybrid the CSD-SSD case. I don't agree that that<br>
> > > > change would be for the best. There are a few reasons for this:<br>
> > > ><br>
> > > > Wayland has always been "what you see is rendered by clients, then<br>
> > > > composited by the compositor". Of course there are cases where this is<br>
> > > > not true, for example there may be effects that are not possible to have<br>
> > > > a client do, but it is the direction we should be working against.<br>
> > > > Making the default CSD-SSD goes against that.<br>
> > > ><br>
> > > > Weston (and mutter for that matter) I assume will never implement the<br>
> > > > default "properly" (i.e. rendering server side shadows). We'd always<br>
> > > > rely on clients implementing optional features to function properly.<br>
> > > ><br>
> > > > It'd effectively make the default case broken and partly unusable in<br>
> > > > any compositor not supporting full the CSD+SSD hybrid solution (i.e.<br>
> > > > server side shadows). In the case where the client doesn't draw any<br>
> > > > shadow, and the server doesn't draw any shadow, it'll also make it hard<br>
> > > > to support interactive resize, since the shadow region is usually used<br>
> > > > as a trigger area for resizing. For example, if you have a border-less<br>
> > > > window, without shadow you'll suddenly have no area where you can let<br>
> > > > your user click-drag to resize the window. The alternative is to have<br>
> > > > logical invisible regions outside of the window implemented by the<br>
> > > > compositor, but that make this even more a hybrid solution, but now also<br>
> > > > with completely invisible special reagions.<br>
> > ><br>
> > > Huh, I always wondered what practical use shadows might have apart<br>
> > > from visual appearance. I can also see how using shadows for any user<br>
> > > interaction while they are outside of the defined window geometry is<br>
> > > going to fail.<br>
> ><br>
> > Why would it fail? It has worked perfectly fine so far. With SSD, this<br>
> > is how things are done as well on X11 - part of the shadow around the<br>
> > window will be available for triggering window resizing. Think of the<br>
> > shadow as part of the window border, instead of just shadow.<br>
><br>
> Is the shadow a part of window decorations but outside of the<br>
> window geometry?<br>
<br>
</div></div>Yes.<br>
<span class=""><br>
><br>
> When you then snap another window beside the first one, you'd snap<br>
> based on the window geometry, right? Then you lose the shadow region of<br>
> the window that happens to be below. The shadow of the window on top<br>
> will extend into and clobber the window below. Or would snap leave a<br>
> shadowy region between the windows? Or do you use window geometry to<br>
> cull the shadow of both windows, in which case you lose it from both on<br>
> the touching egdes?<br>
<br>
</span>Well, the protocol has no say in how snapping would be implemented or<br>
how the compositor draws, but normally snapping would be against the<br>
window geometry. Normally the shadow would clobber the window below,<br>
yes, that is part of the purpose, i.e. to make it clear which window is<br>
above and which is below.<br>
<div><div class="h5"><br>
><br>
> But yeah, I have no idea how that works. I've never had nor wished for<br>
> shadows, so I can't really understand the big deal about them. I'm<br>
> happy having just nice decorations which are accounted into the window<br>
> geometry.<br>
><br>
> > ><br>
> > > > I'd much rather see a solid default which does things "the Wayland way"<br>
> > > > (as described above) that will work reasonably well in a minimalistic<br>
> > > > default weston reference shell, and doesn't imply that the compositor<br>
> > > > should go into effect drawing territory, and I don't think the hybrid<br>
> > > > solution is this.<br>
> > ><br>
> > > I'm not sure there is a "the Wayland way" really for shadows. We did<br>
> > > start with clients just drawing their own shadow as part of the<br>
> > > surface. I assumed that was only because it was very easy to do for a<br>
> > > little bit of eye-candy. We'd have to ask Kristian if there was more<br>
> > > though behind it than that.<br>
> ><br>
> > With "the Wayland way" I really only meant that the compositor, when<br>
> > possible, doesn't spend time rendering eye candy and/or user interfaces.<br>
><br>
> Sure. This brings us to my suggestion of the default by the Wayland<br>
> way: no shadows at all. No implementation is simpler implementation.<br>
><br>
> > > I would hope you can find a way to extract shadows as a separate part<br>
> > > of the protocol where the compositor and client can agree on who draws<br>
> > > it, if at all. I'm sure you'll have exactly the same issue with window<br>
> > > decorations in general, especially considering if shadows are actually<br>
> > > functional rather than just visual.<br>
> ><br>
> > We do indeed need a way to do these negotiations. But we also need to<br>
> > have a sane, workable fallback as well.<br>
> ><br>
> > ><br>
> > > IMHO, the default minimalistic way is no shadows at all for anything.<br>
> > > That would be the Wayland way if any, keeping it simple by default and<br>
> > > everyone equally grumpy ;-). If the compositor then supports shadows on<br>
> > > either server or client side, or both sides by client decision, that<br>
> > > would be something more.<br>
><br>
> Right, so, first sorry for butting in with the above comment. I'm not a<br>
> desktop designer and I don't know how desktop works.<br>
><br>
> I just couldn't stand by and watch how this discussion seemed to<br>
> deadlock at the start where both sides just defend their own<br>
> needs and cannot propose a middle-ground. So I'm here to make you both<br>
> sad. ;-)<br>
><br>
> ><br>
> > It doesn't seem very minimalistic, because it really just means that<br>
> > compositors will need to do server side shadow rendering. Clients,<br>
> > especially the ones not using Qt, GTK+ or EFL, will have much less<br>
> > incentive to add support for it client side, and we'd effectively end up<br>
> > with either having to add all the complexity that server side shadow<br>
> > involves in the compositor, or have an unusable default.<br>
><br>
> No, I do literally mean: no shadows at all by server nor clients,<br>
> unless it is advertised.<br>
><br>
> > If we would to default to no client side shadows, we need to solve the<br>
> > issues such a mode introduces which doesn't rely on server side shadows.<br>
> > I don't know of any solutions.<br>
><br>
> Make the decorations thicker. That's how it worked before shadows were<br>
> invented. Because, really, the shadows *are* just thickening of the<br>
> decorations, especially if you intend to handle input on those regions<br>
> which causes input to not go through to the window below. Whether you<br>
> color it by window background gray or translucent black makes no<br>
> difference.<br>
><br>
><br>
> In IRC you asked what do I propose then. Ok, here's hand-waving. There<br>
> are four different cases:<br>
><br>
> 1) No-one draws any shadows. This is the default. Clients know to not<br>
> rely on shadows, so they will e.g. draw thicker decorations if they<br>
> intend them to be used as handles etc.<br>
><br>
> 2) The server is capable of drawing shadows. The server advertises a<br>
> global "server-shadows". This informs clients that if they don't do<br>
> anything, they will get shadows by the server. The global interface<br>
> could include a request to please don't make me shadows.<br>
><br>
> 3) The server supports client-side shadows. The server advertises a<br>
> global "client-shadows" to note that it supports it, and clients can<br>
> then draw their own shadows. If shadows were the only thing needing the<br>
> window geometry request, it could be in that interface instead of the<br>
> xdg-shell core set.<br>
><br>
> 4) Server supports both ways, so advertises both globals. A client can<br>
> pick which one it wants.<br>
><br>
> With this setup, if you have a client that does not use any of those<br>
> global shadow interfaces, then it will get only server-side shadows if<br>
> the server supports it. Such a client would not draw its own shadows<br>
> and not rely on shadows being there to be usable.<br>
><br>
> The only client implementation not supported by this scheme is when the<br>
> client has no way to *not* draw shadows. How likely is that? Why would<br>
> you need considerably more code to not do something?<br>
><br>
> Here the default behaviour would be accomplished by no-one implementing<br>
> any additional code. If the server does not care about shadows, just<br>
> don't implement anything. If the client does not care about shadows,<br>
> just don't implement anything. If either does care about shadows, then<br>
> you may as well be nice and respect the other party.<br>
><br>
> I phrased that with globals, but I suppose you could also replicate an<br>
> equivalent advertise/support/interface mechanism under xdg-shell too.<br>
<br>
</div></div>I don't think this is a reasonable solution. It will put the burden<br>
on application/toolkit designers to design for a use case which will<br>
never be used since, by design, it's the crappy middle ground no one<br>
will want to use. This wouldn't result in "no implementation" it would<br>
effectively result in an extra implementation that'll probably never be<br>
exercised.<br>
<br>
I think we must at least support drawing a simple window as it has been<br>
done for years now, and with client side decorations that requires a<br>
window geometry which may be smaller than the surface geometry.<br>
<br>
FWIW, popup menus are relevant here as well, as they also have drop<br>
shadow. In the proposed xdg_shell v6 version, xdg_popup's may have<br>
window geometry as well, and this is needed for the positioning system<br>
so that the compositor can place popups within the working area.<br>
<span class=""><br>
><br>
><br>
> Unfortunately, the issue with CSD vs. SSD is not this simple, as<br>
> someone *has to* draw decorations. I claim that we can live without<br>
> shadows, but not without decorations.<br>
><br>
> Also note to everyone else, that I never mentioned anything about the<br>
> user's "freedom" to say anything about the matter. The user wanting one<br>
> or the other is irrelevant here. This is just about making compositors<br>
> and client toolkits agree.<br>
<br>
</span>Indeed. I believe we should support freedom here, and this thread all<br>
about the mode which is supposed to be the "base" mode.<br>
<br>
For the records, the way I imagine this would work is somewhat different<br>
from Pekka's suggestion, as I think the compositor should be the one who<br>
decides the way a client should draw itself, as long as the client<br>
supports it. Described in pseudo protocol, right now we do:<br>
<br>
<- get xdg_surface<br>
<- (xdg_surface.set_maximized/set_fullscreen/set_title, etc)<br>
<- wl_surface.commit<br>
-> xdg_surface.configure(maximized, WxH)<br>
<- wl_surface.attach(buffer)<br>
<- wl_surface.commit()<br>
<br>
With negotiated drawing mode (be it CSD/SSD hybrid (no shadows) or SSD<br>
(no shadow, no window title), it'd just be one extra pair of<br>
configuration state:<br>
<br>
<- get xdg_surface<br>
<- (xdg_surface.set_maximized/set_fullscreen/set_title, etc)<br>
<- xdg_surface.supports_modes(ssd|ssd+csd-hybrid)<br>
<- wl_surface.commit<br>
-> xdg_surface.configure(maximized, WxH, ssd)<br>
<- wl_surface.attach(buffer)<br>
<- wl_surface.commit()<br>
<br>
Whether this eventually would become part of xdg_shell or implemented as<br>
extensions is not practically relevant.<br>
<span class=""><font color="#888888"><br>
<br>
Jonas<br>
</font></span><div class=""><div class="h5">_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a></div></div></blockquote><div><br></div>The client cannot not have any request that says "the compositor must draw the decoration". That would mean that both the client and the compositor must support drawing decorations, making wayland more complex than the current scheme where only the clients must support it.<div><br></div><div>There already are events from the compositor that force the client to turn off some decorations. They may be hard to see, but they are the "maximize" and "fullscreen" states. "maximize" requires turning off the shadows and "edges" of the surface. "fullscreen" requires turning off all decorations. Therefore it is already established that clients must be able to obey instructions from the compositor to remove decorations, so I don't think "negotiation" is necessary.</div><div><br></div><div>event xdg_surface.configure(WxH, ssd)<br></div><div><br></div><div> The ssd flags indicate what pieces of the decoration should *not* be drawn. This is either because the compositor does not want them, or because it is drawing it themselves:</div><div><br></div><div> 4 flags for shadows on top, right, bottom, left</div><div> 4 flags for "edges" on top, right, bottom, left</div><div> A flag for the titlebar</div><div> others?</div><div><br></div><div> Note that there is no longer any indication of fullscreen or maximized, it is implied by the settings of these flags.</div><div><br></div><div> The reason for a per-edge flags is to allow horizontal or vertical maximization, and snapping to the edges of outputs.</div><div><br></div><div><div>The compositor wants to be able to preview snapping locations without telling the client to reconfigure, and to be able to turn decorations on/off without resizing the window contents. This can be supported by the client telling the compositor about various regions of the surface. The compositor can also use this to detect clients that ignore the decoration-removal requests, and crop off the unwanted decorations. The regions are probably also useful to simulate close and resize of clients that are not responding to pings.</div></div><div><br></div><div>request xdg_surface.set_region(enum, ...)</div><div><br></div><div> Inform the compositor of what region of the window serves a given purpose, so it knows what size to use if it removes some decoration, can accurately preview snapping locations, and can hide unwanted decorations. If clients don't send this the compositor will have to guess from the api version and from wl_surface regions. All of this is double-buffered. Possible regions:</div><div><br></div><div> geometry: with the shadows removed. Same as wl_surface input region?</div><div> title+content: with the shadows plus edges removed, but titlebar still there</div><div> content: with all decorations removed</div><div> closebox: region where clicks should kill the client if it does not respond to pings</div><div> ... probably others ...</div><div> </div></div><br></div></div>