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
danvet has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
zebrag has quit [Quit: Konversation terminated!]
immibis is now known as Guest2472
immibis has joined #wayland
Guest2472 has quit [Ping timeout: 480 seconds]
cvmn has joined #wayland
ybogdano has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
cvmn has quit [Ping timeout: 480 seconds]
<RAOF>
Really, the problem with all the screencasting protocols is that they're all dancing around the fact that they really want the screencast client to act as a server; they should all have the screencast _client_ publish a set of buffer-allocator interfaces and then have the compositor allocate buffers from the client and submit them in a reverse wl_surface fashion.
<RAOF>
Likewise, cursor-or-not-cursor is just wl_subsurface in reverse.
<RAOF>
Actually, you could _just do that_, couldn't you. The screencast initiation protocol becomes “here's an fd you `wl_display_connect_to_fd` on and start talking”. Heh.
<RAOF>
For maximum confusion!
luna has quit [Ping timeout: 480 seconds]
<emersion>
RAOF: why do you believe the server should allocate buffers?
<RAOF>
Because the server is the participant which is generating the images, in much the same way that the client allocates the buffers for regular `wl_surface`s
<emersion>
that doesn't work, no
<emersion>
the server would do too much work if it pushes frames to the client, and resource accounting doesn't work
<emersion>
the client might have requirements on the buffers, e.g. to make them compatible with vaapi
<RAOF>
The server can do backpressure in the same way that clients do backpressure.
<emersion>
then there's no point in having the server allocate the buffers anymore
<RAOF>
?
<emersion>
if the client needs to send a backpressure "go on" request, then you might as well add a buffer arg to it
columbarius has quit [Read error: Connection reset by peer]
rv1sr has joined #wayland
columbarius has joined #wayland
jgrulich has joined #wayland
danvet has joined #wayland
hardening_ has joined #wayland
hardening has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
MajorBiscuit has joined #wayland
mvlad has joined #wayland
rasterman has joined #wayland
Major_Biscuit has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
m5zs7k has quit [Ping timeout: 480 seconds]
m5zs7k has joined #wayland
fahien has joined #wayland
<any1>
I did think about doing things v4l2 style where the client would submit a collection of buffers to the compositor with associated ids and the compositor would feed those ids back the the client.
<any1>
It might be useful for clients that do everyting on the same thread, so that they can work past "the deadline", but other than that it doesn't seem very useful
<any1>
Polling for updates is a lot simpler than implementing back-pressure.
Leopold_ has joined #wayland
<any1>
As was discussed in a previous thread on ext-screencopy: the only benefit of having the compositor push buffers is that it's possible to implement in such a way that frames don't get dropped when the size of the captured area changes.
<markbolhuis>
Hi all, after creating a xdg_toplevel, and then commit, I call wl_display_sync. I'm expecting the wl_callback.done event to be sent after the initial xdg_surface.configure event. However in both Kwin and Sway it's happening before. The spec states that events must be handled in order, which isn't happening here.
rv1sr has quit []
<kennylevinsen>
markbolhuis: Events are handled in order, but I don't think the spec states that the configure event must be sent immediately.
<markbolhuis>
wl_display_roundtrip has the same behavior but before the function exits it has dispatched xdg_surface.configure as well
<markbolhuis>
Quoting xdg-shell.xml: "After creating a role-specific object and setting it up, the client must perform an initial commit without any buffer attached. The compositor will reply with an xdg_surface.configure event."
<markbolhuis>
wayland.xml: "Since requests are handled in-order and events are delivered in-order, this can be used as a barrier to ensure all previous requests and the resulting events have been handled."
<markbolhuis>
Seems clear to me that a done event must be emitted after any surface configure event
<kennylevinsen>
it does not specify that the event will be fired immediately
<kennylevinsen>
all events are handled in order as the spec demands
<kennylevinsen>
specifically, what wl_display_sync ends up guaranteeing is that the server has received all prior requests
<kennylevinsen>
(becuase the server got to your sync message and responded, and thus must have read all prior ones as well)
<markbolhuis>
and the: "resulting events have been handled" bit?
<kennylevinsen>
events are messages from the server, so "events have been handled" means that your client read everything sent up until that point and dispatched callbacks
<kennylevinsen>
if the server hasn't sent it yet, it won't be handled
Leopold_ has joined #wayland
immibis is now known as Guest2505
immibis has joined #wayland
<kennylevinsen>
note that a normal client should not use display roundtrip - it's a utility function to make e.g. tests, small utilities or very simple code easy to write. Instead, a normal client should just react to events - in your case, through the configure listener. You need to listen to it anyway.
<markbolhuis>
That is really unclear imo. I though the whole point of sync requests was as the spec says, to act as a barrier.
<markbolhuis>
Yes that's the thing, I'm trying to eliminate roundtrips
<kennylevinsen>
and it does just that, it acts as a barrier - barriers are just useless for requests handled asynchronously. A useful case is wl_registry, where the server starts sending stuff and you might want to wait until it sent everything. If it has time to look at your sync request, it means its done.
<kennylevinsen>
most things in wayland are asynchronous
<kennylevinsen>
markbolhuis: well, roundtrip == display_sync. That's what roundtrip does.
<kennylevinsen>
markbolhuis: again, you can validate what's going on by setting WAYLAND_DEBUG=1 before running your client
<markbolhuis>
Yes, exactly, by the time the done event is dispatched on the client side I can be sure that all globals have been been sent and dispatched as well. Why should it only apply here?
Guest2505 has quit [Ping timeout: 480 seconds]
<kennylevinsen>
markbolhuis: Becuase the registry is defined as sending the globals immediately when you call get_registry. So, if the server processes a sync request, it means it's done sending.
<kennylevinsen>
here, the configure event is *not* sent immediately
<kennylevinsen>
wlroots never sends configure events immediately - instead, they're postponed until the event loop enters the idle state (i.e., everything else is handled)
<kennylevinsen>
the reason being that many things trip configure events, so instead of spamming them every time a configure-inducing change is made, we wait until there's nothing more to do and send one configure for everything.
<kennylevinsen>
I think that's perfectly in line with spec - wl_display_sync just isn't the right tool if you want to wait for a callback - that's what the callback is for. :)
Seirdy has quit []
<markbolhuis>
Right, That is super unclear. Both GLFW and SDL make this mistake then
<markbolhuis>
The protocol needs to document which requests are responded to before a done event, and which ones aren't
<kennylevinsen>
ah, nothing is responded to before a "done" event. wl_display_sync is a ping, it has no side-effects of any kind.
<kennylevinsen>
but what *could* be clearer is which requests immediately fire an event
ybogdano has joined #wayland
<markbolhuis>
Sorry if I'm being a bit slow here, what guarantees does sync actually provide then? From my perspective it now appears useless.
<markbolhuis>
"ah, nothing is responded to before a "done" event." except registry global events, right?
<kennylevinsen>
none: It's a request that triggers an event. As all requests are handled in order, it means that the server did what it was doing and processed all previous messages. As all events are handled in order, it means that all events *you have received* have been read and had their callback fired.
<markbolhuis>
Right
<kennylevinsen>
The reason it works for the registry is that get_registry emits global events immediately. This means that it won't look at your display_sync request until its done.
<markbolhuis>
That needs documenting
<kennylevinsen>
as mentioned, which requests *immediately* emit something could use clarification.
perr has quit [Ping timeout: 480 seconds]
<kennylevinsen>
feel free to open an issue about it
<markbolhuis>
Ok, well, thanks a lot for your help. I will
zebrag has joined #wayland
rv1sr has joined #wayland
Seirdy has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
Brainium has quit [Quit: Konversation terminated!]
markbolhuis has quit [Quit: markbolhuis]
fahien has quit []
immibis has quit [Remote host closed the connection]
immibis has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
columbarius has quit [Remote host closed the connection]
columbarius has joined #wayland
Major_Biscuit has quit [Ping timeout: 480 seconds]
devilhorns has quit []
jgrulich has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
fmuellner_ has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
ybogdano has joined #wayland
Leopold_ has joined #wayland
dreda has quit [Read error: No route to host]
dreda has joined #wayland
dreda is now known as Guest2518
andyrtr_ has joined #wayland
andyrtr has quit [Read error: Connection reset by peer]
andyrtr_ is now known as andyrtr
Guest2518 is now known as dreda
markbolhuis has joined #wayland
sav10 has joined #wayland
devilhorns has joined #wayland
sav10 has quit []
luna has quit [Read error: Connection reset by peer]
devilhorns has quit []
___nick___ has quit [Ping timeout: 480 seconds]
luna has joined #wayland
mvlad has quit [Remote host closed the connection]
Azem has quit []
sav10 has joined #wayland
fmuellner has joined #wayland
luna has left #wayland [#wayland]
dcz_ has quit [Ping timeout: 480 seconds]
markbolhuis has quit [Quit: markbolhuis]
rv1sr has quit []
clever has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
jmdaemon has joined #wayland
buh0 has joined #wayland
buh0 has quit [Quit: Bye!]
ybogdano has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
hardening_ has quit [Ping timeout: 480 seconds]
unrelentingtech has left #wayland [#wayland]
manuel_ has left #wayland [#wayland]
ybogdano has joined #wayland
sav10 has quit []
abeltramo5391 has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]