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
creich has quit [Quit: Leaving]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Shimmy0400 has joined #wayland
Shimmy040 has quit [Read error: Connection reset by peer]
cvmn has joined #wayland
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110_ has joined #wayland
cool110 has quit [Ping timeout: 480 seconds]
cvmn has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
smallville7123 has joined #wayland
buh0 has quit [Quit: Bye!]
rv1sr has joined #wayland
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
cvmn has joined #wayland
caveman has quit [Remote host closed the connection]
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
manuel__ has quit [Ping timeout: 480 seconds]
jgrulich has joined #wayland
danvet has joined #wayland
adarshgm has joined #wayland
sav10 has joined #wayland
tzimmermann_ has joined #wayland
hardening has joined #wayland
tzimmermann has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
sav10 has quit [Read error: No route to host]
kts has joined #wayland
sav10 has joined #wayland
dcz_ has joined #wayland
pym_ has joined #wayland
pym_ has left #wayland [#wayland]
rgallaispou has left #wayland [#wayland]
rasterman has joined #wayland
rgallaispou has joined #wayland
manuel__ has joined #wayland
<pq>
yshui`, the problem with EGL Wayland platform is that the app needs to be very careful in order to be sure the eglSwapBuffers calll will attach and commit a buffer of the right size. Sounds like eglgears_wayland is simply buggy. If the window was maximized, it would hit a protocol error.
<pq>
yshui`, a client is free to use old size until it acks a new size, and compositors must deal with that. But once the client acks, then it's done and protocol contraints must be obeyed.
<pq>
smallville7123, I get a feeling you have a fundamental misunderstanding there somewhere. For example, clients do not need to send a new buffer every time the compositor wants to repaint an output. The compositor holds on to the client's window image contents, so that it can repaint at any time without needing anything from any client.
<pq>
only when a client provides updated window content, the compositor forgets about the previous content. So content for a window is always available in the compositor.
<pq>
smallville7123, and no, compositors do not use sleeps. They poll for file descriptors for client requests and display hardware events, and timers. For a compositor it is important to return ASAP to its main event loop to wait for the next thing.
d_ed has joined #wayland
smallville7123 has quit [Ping timeout: 480 seconds]
<dottedmag>
pq: Well, if you have a compositor in a language that provides lightweight multitasking and implicit event loop, then some tasks might sleep. You probably meant in a C world compositor does not sleep?
sav10 has quit []
manuel_ has joined #wayland
manuel__ has quit [Read error: Connection reset by peer]
tzimmermann_ has quit []
tzimmermann has joined #wayland
adia4 has joined #wayland
MajorBiscuit has joined #wayland
<pq>
dottedmag, of course a compositor written in C sleeps too. It just sleeps in a poll() or equivalent call, and never blocking in nanosleep(), so to say.
<pq>
dottedmag, I would be very surprised if a task blocked in nanosleep-equivalent was appropriate in any language.
<emersion>
right, talking about syscalls here
<pq>
since that would mean the task is by definition not responding during that time and cannot do anything even if it needed to
<any1>
Ever read plc code? :)
<any1>
Oh, actually, I misremembered. In PLC, they run in endless cycles and wait for counters to reach certain values.
smallville7123 has joined #wayland
<smallville7123>
alright
<yshui`>
pq: not just eglgears, winit is doing that as well. i wonder if it's more wide spread.
<yshui`>
in theory the client can choose to ignore the size suggestion and then at some slightly later point spontaneously choose to use a new size that happens to match the one the compositor asked for, right? 😅
<pq>
yshui`, if the client never acks the configure events, theoretically, yes.
<pq>
but since some compositor side window state changes may be triggered by the ack, that's not a good idea.
<kennylevinsen>
pq: can't a client can ack and disagree with the size as long as it is not maximized?
<pq>
kennylevinsen, sure, but that's different since it ack'd.
<pq>
it's "unfriendly" but not illegal
<pq>
in any case, the sequence: ack, use old size, use ack'd size; is clearly buggy, even if it's not illegal
<kennylevinsen>
agreed
<kennylevinsen>
Technically legal, but undeniably broken
<yshui`>
i agree too, but this is not enforceable from the protocol side, and since it's technically legal i don't know if i can go around and ask people to fix that.
<kennylevinsen>
that's the "undeniably broken" part :P
<pq>
you definitely should ask to fix it
<pq>
If an application intends to show a cat picture, and instead it shows a horse picture, it's not enforceable or a bug from protocol perspective, but the app is still broken. :-)
<pq>
EGL Wayland platform in particular is difficult to make work right wrt. this, because there are many EGL and OpenGL API calls that will "lock" the size of the next rendered buffer, and this API is not annotated to do so in any way.
<pq>
Basically any API call that requires a buffer will lock the buffer size for the next frame, causing any resizing attempts to be delayed to the following frame.
cnsvc- has joined #wayland
<pq>
so the best time to set the size of the next frame is immediately after eglSwapBuffers() before doing anything else.
<pq>
I would say that sending ack from the configure event handler is always ill-adviced if not a bug, because it gives the wrong impression when reading code. And I think Weston demos have always done so...
cnsvc has quit [Ping timeout: 480 seconds]
<kchibisov>
I wonder what the interaction should be wrt frame callbacks and resizes. With EGL you basically must resize only once per frame callback, multiple can occur though. So to ack the size you'll use you need for windowing library like winit incorporate frame callbacks to account that and hope the cleint draws.
<kchibisov>
Right now for example what we're doing is acking configure and then asking application to resize with the size compositor send to us.
<kchibisov>
From my understanding the right place for ack right before drawing?
<pq>
yes, the right place to ack is right before drawing, when you are certain you are going to draw with the state you are acking.
<kchibisov>
I'm just saying that it would be nice if compositor will send configure once per frame event...
<pq>
nope, can't guarantee that.
mvlad has joined #wayland
<pq>
the app should query the library for the current window state that is going to be ack'd at the beginning of draw.
<kchibisov>
The problem is that app is drawing, not the library.
<pq>
why does that make a difference?
<kchibisov>
I have no clue wether the app drawn or not.
<pq>
you do ask the app to re-draw somehow, right?
<kchibisov>
I do, it can ignore.
<pq>
sure, so that's all.
<pq>
Instead of telling app "draw w,h" you tell "you should re-draw now". And during draw, the app asks the lib what the state should be, and then draws whatever it wants.
<pq>
it makes no difference if the app re-draws in a busy-loop, or waits for events
<kchibisov>
The problem is that state is broadcasted and adding .will_draw() like function sounds wrong.
<pq>
if the app doesn't re-draw, there is nothing you could do about that anyway
<pq>
I don't understand where .will_draw() would come from.
<kchibisov>
I mean I can't solve it because there're frame callbacks driven loops.
<pq>
the main point is that you ack the configure events from draw function, and not from configure handlers.
<kchibisov>
For example configure event forces winit to tell app to redraw.
<kchibisov>
But then app could use frame callbacks meaning that it won't draw anyway.
<pq>
why is that a problem?
<kchibisov>
My point is that draw function is not visible to winit and clients can't ack on their own.
<pq>
surely apps call *something* to post their drawing?
<kchibisov>
eglSwapBuffers.
<kchibisov>
This is outside of the winit.
<pq>
and you did not wrap eglSwapBuffers in your lib?
<kchibisov>
It's in a separate lib without wayland connections what so ever.
<pq>
then you do get to add a ".will_commit_now()" API
<kchibisov>
That's what I'm saying...
<pq>
that's what you designed for
<pq>
not will_draw, but will_commit
<kchibisov>
Yes, but you don't have such concepts on other OSes.
<pq>
or call it send_window_state or something
<pq>
then it's a no-op on other OSs
<kchibisov>
I mean that `commit` isn't a name macOS user would understand.
<kchibisov>
They search docs for like draw or anything like that so they at least put it.
<pq>
right, so send_window_state, update_window_state, etc.
<pq>
you do need functions for asking window states, too
<pq>
and an API to tell the app what window state it actually got
<kchibisov>
I mean they get events for the state.
repetitivestrain has joined #wayland
<kchibisov>
Everything is exposed except the 'send ack from the client'.
<pq>
That sounds like a problem.
<kchibisov>
Yes, but I never seen an issue due to that in a wild.
<pq>
ok
<kchibisov>
It's not like it won't be fixed. It surely will be.
<pq>
to come back to the functions that lock the buffer size in EGL, asking for buffer_age is one.
<kchibisov>
pq: the most important function that locks the buffer is eglMakeCurrent and eglCreateContext if you have any context current.
<kchibisov>
Which is a mesa bug but it's what it is.
<pq>
aha
<kchibisov>
Most other functions are expected to lock, but these ones are weird.
<pq>
yeah
<kchibisov>
Since if you have multiple windows you should somehow figure out that you must call wl_egl_window_resize(whatever it called) and then make context current for the window.
<kchibisov>
And when you decide to add new window you must make not current for all context you manage.
<kchibisov>
Otherwise the current one will end up locking.
<repetitivestrain>
hi there, i think i've found (once again) either a bug in firefox or a bug in my compositor: firefox creates a lot of desynchronous subsurfaces, but doesn't always commit the parent after receiving a configure event. instead, it only does ack_configure, and commits one of the subsurfaces instead
<repetitivestrain>
so in that case my compositor will continue to keep firefox's surface "frozen", since the xdg_surface was not committed after ack_configure
<repetitivestrain>
i mean from the compositor with debugging on and firefox connected
<repetitivestrain>
firefox doesn't commit the surface with the xdg_surface role after ack_commit (6)
<repetitivestrain>
it commits an attached desync subsurface (wl_surface@40) instead
<yshui`>
i am trying to follow the conversation. iiuc, the problem with ack_configure is that it crossed abstraction boundaries? the windowing library is responsible of sending ack, but the graphic library is responsible for setting up the buffers?
<yshui`>
i don't quite understand what locking means here though
<repetitivestrain>
are there two conversations wrt ack_configure going on at the same time
<yshui`>
yeah 😆
<smallville7123>
pq: ok
<pq>
yshui`, locking means that EGL implementation has chosen the buffer to be drawn into next, which means that the frame size has been decided and cannot be changed before the next eglSwapBuffers.
<kennylevinsen>
repetitivestrain: compare with a run under weston or similar
<pq>
so if you try to call wl_egl_window_resize(), it won't actually be effective until *after* that eglSwapBuffers
<kennylevinsen>
firefox is tricky, as the normal surfaces tend to be managed by Gtk, while firefox itself just manage the subsurfaces.
<yshui`>
ah i see. so even the user of the graphic library won't know exactly when the ack could be sent.
<yshui`>
sounds like this is going to be tricky to fix then
<pq>
yshui`, the app could know, but it does not want to know, because it's very specific to Wayland and the concept is unheard of elsewhere.
<yshui`>
kchibisov: thanks
<yshui`>
since it's not causing problems in the wild, maybe this requirement could be dropped instead?
<pq>
what requirement?
<yshui`>
the make required changes before acking
jmdaemon has quit [Ping timeout: 480 seconds]
<yshui`>
requirement
<kennylevinsen>
yshui`: acking incorrectly will lead to problems. e.g., sway's transactional resize system - needed for pixel-perfect tiled resizing - relies heavily on it.
<pq>
it makes no difference whether a client acks first and draw second, or vice versa, as long as *both* ack and drawing end up in the same commit.
<kchibisov>
kennylevinsen: the current situation that winit will always draw with the size they've acked, they can just ack more than once.
<kchibisov>
It's not like they ack wrong size...
<kchibisov>
It's more like configure -> ack -> configure -> ack ... ack -> draw.
<kennylevinsen>
kchibisov: the example yshui` gave involves ack, then commit the old size a few times, and then finally commit the new size
<kchibisov>
Nah, winit can't do that.
<pq>
if there is no commit in between then I guess that's valid?
<kchibisov>
pq: there's no commit.
<yshui`>
pq: isn't the problem that egl could lock the buffer so that size is only updated in next next commit?
<kchibisov>
The commit will be done in the app that will do drawing.
<kennylevinsen>
kchibisov: the original example was not winit, so that might be true :)
<pq>
yshui`, yes.
<kchibisov>
kennylevinsen: they mentioned winit...
<kchibisov>
yshui`: yes with egl + winit it's tricky, but plain winit can't do that.
<pq>
yshui`, so if you are using EGL and EGL has locked the size, you must not ack any further configures until you've done the swap.
<kchibisov>
pq: that's what I expect as well.
<kennylevinsen>
kchibisov: does it ack the same serial multiple times? because that's an error.
<kchibisov>
kennylevinsen: no, each time new one.
<kennylevinsen>
yeah then that's all good
<repetitivestrain>
kennylevinsen: firefox has the same problem under weston
<repetitivestrain>
i found the reliable way to reproduce it is to run "firefox -P"
<yshui`>
hmm, going all the way back to my original question. i was expecting `(receives configure event) -> set_window_geometry -> attach_buffer -> ack -> commit`, but sounds like as long as `ack` and `attach_buffer` etc are in the same commit, the order doesn't matter?
<pq>
kchibisov, what I meant before is that sending acks from configure events handlers is bad form, but not necessarily a bug depending on everything else going on. It would be safer to not do that, but if you otherwise guarantee a correct protocol sequence, that's fine.
<repetitivestrain>
the profile selector popup will not be displayed
<kchibisov>
pq: winit can't commit surface so it should be good.
<kchibisov>
It forces the app to redraw meaning that it'll commit.
<pq>
yshui`, in the same commit, yes.
<yshui`>
ok, that clears it up. then what i observed from winit is conformant.
<yshui`>
only eglgears is weird.
<pq>
kchibisov, is it guaranteed that the app will always draw *after* the ack you sent?
<kchibisov>
pq: I force it to redraw so it'll do that :p
<kchibisov>
if it's not it's not problem.
<kchibisov>
my problem*
<pq>
and not like, receive configure event, ack it, send event to app, app repaints, app receives the event
<kchibisov>
No, the order is strict and there're events on which you must draw.
<pq>
sounds fine then
<kchibisov>
I'm not sure how it'll go with multithreaded env since app can always draw...
<pq>
aaaand not :-p
<kennylevinsen>
repetitivestrain: if it doesn't display in weston, file a firefox bug? Make sure to try firefox nightly though.
<pq>
well, depends
<kchibisov>
I'll just need a good multithreaded multi window client to test that.
<repetitivestrain>
kennylevinsen: sure (problem being i can't firefox nightly on this machine, so it's the latest fedora has)
sav10 has joined #wayland
<kchibisov>
But my feeling is that if the app draws ondemand it should be fine, since the event comes from the main thread, and for contiguous drawing app it doesn't matter.
<kchibisov>
Since it's something like a game or whatever.
<pq>
kchibisov, how would it not matter for continuous draws?
<pq>
games cannot be made maximized and windowed?
<kchibisov>
They could (from my expereince they try hard to not and restrict them to even special monitors).
<pq>
I mean, outside of 1st/3rd person shooters alike?
<kchibisov>
I mean for contigous drawing you'll commit right away the ack.
<pq>
sure, but did you actually resize the buffer to the right size for the commit carrying the ack?
<kchibisov>
It's up to the client to resize.
<pq>
I guess I'm not sure what kind of threading you are thinking of
markbolhuis has joined #wayland
<pq>
does one thread send the ack, and a different thread does the commit?
<kchibisov>
The one when you have wayland queue on the one thread, but window handles on other threads.
<kchibisov>
So you have one thread per window and dispatch events from main queue to them.
<pq>
that's dispatch, but here we are talking about sending
<kchibisov>
I mean the windows are attached to main queue and don't have separate queues on their threads.
<pq>
ok
<kchibisov>
So the event is send by the library and not by the wayland infra.
<pq>
libwayland queues are irrelevant for sending, though
<pq>
I'm not sure what you mean by "the library" vs. "wayland infra"
<pq>
there are no multiple queues for sending in libwayland-client, there is only one send buffer for the connection, and it's written by any request sending function one at a time.
<pq>
Sending ack from one thread and commits from another would be inherently racy, so I'd like to hear that's not what would happen. :-p
<pq>
:-)
<kchibisov>
It's likely what could happen with multiple threads.
<kchibisov>
It just with contiugous drawing you'll send commit again after that ack with the correct size.
<pq>
how do you know it's the correct size and not old size?
<kchibisov>
App queue for size on a window.
<kchibisov>
query&
<kchibisov>
And it's not event, but simple mutex that gots updated.
<pq>
I'm confused because earlier you seemed to imply that apps don't query, the get "broadcast".
<kchibisov>
We have both mechanism in place.
<pq>
what guarantees that more acks are not sent between that query and actual commit?
<kchibisov>
The event queue isn't read, so there's no ack.
<pq>
I'm talking about the ack_configure wayland request.
<pq>
do you mean something stops dispatching the Wayland events in the main thread?
<kchibisov>
Yes it's stopped until it dispathes everything to the client and telling it to draw.
DPA has quit [Ping timeout: 480 seconds]
<kchibisov>
Then after drawing events are clearing it starts dispatching again.
<pq>
but it's on a different thread? How do you know other window threads are not committing at the same time the main thread it dispatching and acking a configure event?
<kchibisov>
I guess that's the issue I should try to solve.
<pq>
heh
<pq>
I'm also wondering how you can do "dispatches everything" *and* "telling it to draw" - I guess the handler callbacks are forbidden from drawing?
<kchibisov>
We send event telling to do drawing.
<kchibisov>
We don't call to client from wayland callbacks and such if that's what you mean.
adarshgm has quit [Ping timeout: 480 seconds]
GentooPhysicist393542 has quit []
DPA has joined #wayland
kts has quit [Quit: Leaving]
bodiccea has quit [Remote host closed the connection]
bodiccea has joined #wayland
pym_ has joined #wayland
pym_ has left #wayland [#wayland]
kts has joined #wayland
bodiccea has quit [Remote host closed the connection]
bodiccea has joined #wayland
bodiccea has quit [Remote host closed the connection]
bodiccea has joined #wayland
<smallville7123>
are there any libraries that could replace wayland's socket/fd server/client ?
<smallville7123>
or must wayland use its own implementation cus other libs fail to meet wayland's requirents ?
smallville7123 has quit [Ping timeout: 480 seconds]