ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
d42 has quit [Read error: Connection reset by peer]
<repetitivestrain>
hi there, i have a small question about xdg_decoration
<repetitivestrain>
the documentation for zdg_toplevel_decoration_v1::set_mode says
<repetitivestrain>
* Set the toplevel surface decoration mode. This informs the
<repetitivestrain>
* compositor that the client prefers the provided decoration mode.
<repetitivestrain>
*
<repetitivestrain>
* After requesting a decoration mode, the compositor will respond
<repetitivestrain>
* by emitting an xdg_surface.configure event. The client should
<repetitivestrain>
* then update its content, drawing it without decorations if the
<repetitivestrain>
* received mode is server-side decorations. The client must also
<repetitivestrain>
* acknowledge the configure when committing the new content (see
<repetitivestrain>
* xdg_surface.ack_configure).
<repetitivestrain>
<repetitivestrain>
ah damn, sorry for the broken formatting
<repetitivestrain>
basically, it says it should emit a configure event immediately
<repetitivestrain>
without an associated toplevel configure, i assume
<repetitivestrain>
but what chromium seems to depend on is what kwin does, which is to wait for the next commit on the xdg_toplevel's surface
<repetitivestrain>
and to send decoration configure event along with the initial configure event with a width and height of 0 0 on the xdg_toplevel
<repetitivestrain>
which behavior is correct here? my reading of the documentation, or what kwin does?
<repetitivestrain>
thanks in advance
fmuellner has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
ybogdano has quit [Read error: Connection reset by peer]
Leopold_ has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
cool110_ has joined #wayland
cool110 has quit [Remote host closed the connection]
Company has quit [Quit: Leaving]
dcz_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
<vyivel>
repetitivestrain: i don't see it anywhere saying that the configure must be sent *immediately*
<vyivel>
and it can be associated with a toplevel configure, e.g. if changing decoration mode changes the surface's size
hardening has joined #wayland
immibis has quit [Ping timeout: 480 seconds]
<repetitivestrain>
vyivel: but it can't be valid to wait for the initial commit sent after get_toplevel, right? basically, imagine this:
<repetitivestrain>
<repetitivestrain>
- client gets toplevel from xdg_surface
<repetitivestrain>
- client creates decoration for toplevel
<repetitivestrain>
- client sets decoration mode and begins waiting for configure
<repetitivestrain>
- the configure never arrives, because the toplevel commit did not happen (client gets stuck here)
<repetitivestrain>
- client commits toplevel, gets a configure event from the toplevel, attaches a buffer, commits again, and goes on its way
<repetitivestrain>
that's what could happen if sending the decoration configure waited for the initial toplevel configure
<repetitivestrain>
and i don't see any wording in the spec that says a client shouldn't wait for configure to arrive before performing the initial commit on the toplevel
<vyivel>
before the first null-buffer commit xdg_surface is basically incomplete
<vyivel>
because the client could add more information that would affect compositor's decisions
<vyivel>
sending a configure to a surface that never committed doesn't make sense to me
<vyivel>
in the case of decorations, the configure reply is supposed to tell the surface what size/states it should assume in response to the mode request
<vyivel>
it's useless if the surface isn't initialized completely
hardening has quit [Ping timeout: 480 seconds]
WhizzWr has quit [Quit: Bye!]
WhizzWr has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
<repetitivestrain>
vyivel: then shouldn't that be written/made clear in the spec?
<repetitivestrain>
i.e. something like this: "If set_mode is issued before the initial commit of the xdg_toplevel's surface, then the corresponding configure event may only be sent by the compositor together with the initial xdg_toplevel::configure event sent once the initial commit is made with no buffer attached?"
<repetitivestrain>
<vyivel>
i don't think it's necessary
<repetitivestrain>
vyivel: why not? it does make sense to me if the compositor implements decorations aside from the rest of the surface state
<repetitivestrain>
like in mine, where the decorations are provided by a different process based on a flag set on the toplevel
<repetitivestrain>
which is set at the next commit after all configure events (generated by the xdg_decoration) have been acked
<repetitivestrain>
xdg_toplevel_decoration*
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
<vyivel>
the client shouldn't really rely on receiving a configure in reply to a state change request
<repetitivestrain>
while being racy after the toplevel is mapped, a toplevel freshly gotten from the xdg_surface can't possibly get other configure events, right?
<repetitivestrain>
anyway the reason i'm asking is that chromium relies on the very specific order of getting configure events from the toplevel
<repetitivestrain>
it creates a decoration resource and then commits the buffer
<repetitivestrain>
commits no buffer*
<repetitivestrain>
the first xdg_surface::configure (not xdg_toplevel::configure) issued is considered the initial configure and the geometry inside any corresponding xdg_toplevel::configure is ignored
<vyivel>
if i was making a client, i wouldn't expect to receive a configure before the initial wl_surface.commit tbh
<repetitivestrain>
but that's not what the text input spec makes it seem like
<repetitivestrain>
so why not write it down to avoid this ambiguity
* vyivel
shrugs
<vyivel>
create an issue on w-p tracker if you want
jmdaemon has quit [Ping timeout: 480 seconds]
<repetitivestrain>
sure but it will probably take time to get a gitlab.fdo account
<repetitivestrain>
my job has stupid rules regarding these
<repetitivestrain>
job contract*
<repetitivestrain>
so if someone else could do that i'd be pretty grateful
jmdaemon has joined #wayland
<vyivel>
likewise, i don't think there's a reason to immediately send a configure in reply to e.g. xdg_toplevel.set_maximized request during the initial setup
danvet has joined #wayland
<repetitivestrain>
i understand that, but it's ambiguous, especially since being maximized is arguably much more connected to the surface buffer state than whether or not it is decorated
<vyivel>
not much really
<vyivel>
oh well
<vyivel>
i'll open an issue
<repetitivestrain>
thanks
Leopold_ has quit [Remote host closed the connection]
<vyivel>
indentation is done with spaces, expect when 8 spaces are replaced with tabs, except for two lines
lucasta has quit [Ping timeout: 480 seconds]
lucasta has joined #wayland
lucasta has quit [Ping timeout: 480 seconds]
midgard has quit [Quit: Bye]
midgard has joined #wayland
lucasta has joined #wayland
lucasta has quit [Ping timeout: 480 seconds]
<dottedmag>
xdg_surface doc says "The client must call wl_surface.commit on the corresponding wl_surface for the xdg_surface state to take effect." — what state "takes effect" on configure? Only the state that explicitly says it is double-buffered, like xdg_toplevel::set_max_size, or something else?
<vyivel>
set_window_geometry?
<vyivel>
there's a very similar statement for xdg_popup but not sure what it refers to
<vyivel>
for toplevel, it's set_{max,min}_size
<vyivel>
hm
<vyivel>
"States set in this way are double-buffered. They will get applied on the next commit."
<vyivel>
i don't understand what this means
<vyivel>
considering that states are sent with an xdg_toplevel.configure event and aren't stored anywhere
<vyivel>
well, the event has to be ack'ed, but then a commit is to be expected anyway in order to apply the ack'ed state
lucasta has joined #wayland
lucasta has quit [Ping timeout: 480 seconds]
Lucretia has quit [Read error: Connection reset by peer]
lucasta has joined #wayland
Lucretia has joined #wayland
lucasta has quit [Remote host closed the connection]
<dottedmag>
vyivel: next commit is wl_surface::commit, right?
<vyivel>
yes
<dottedmag>
yeah, the wording is bit unclear. I suppose it made sense when the only states were maximized/fullscreen and referred to set_maximized/set_fullscreen
evon37788 has joined #wayland
<vyivel>
those are just requests btw, and they aren't double-buffered