crater21508 has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-04 00:50:57)]
pnowack has quit [Quit: pnowack]
Mick has joined #wayland
Mick is now known as Guest795
Guest795 has quit [Remote host closed the connection]
Lalufu9 has joined #wayland
Lalufu9 has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-04 01:07:15)]
co2umbarius has joined #wayland
adjtm has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
co3umbarius has joined #wayland
co2umbarius has quit [Ping timeout: 481 seconds]
boistordu_old has joined #wayland
boistordu has quit [Ping timeout: 480 seconds]
sunri5e has joined #wayland
sunri5e has quit [Remote host closed the connection]
madog has joined #wayland
madog has quit [Remote host closed the connection]
rgallaispou1 has joined #wayland
rgallaispou2 has joined #wayland
rgallaispou1 has quit [Read error: Connection reset by peer]
rgallaispou has quit [Ping timeout: 480 seconds]
shankaru1 has joined #wayland
Savagedlight has joined #wayland
Savagedlight has quit [Remote host closed the connection]
search_social20 has joined #wayland
search_social20 has quit [Remote host closed the connection]
blue__penquin has joined #wayland
zeylos has joined #wayland
zeylos has quit [Remote host closed the connection]
pieguy128 has joined #wayland
joes has joined #wayland
joes has joined #wayland
DarkTrick has joined #wayland
hardening has joined #wayland
danvet has joined #wayland
ppascher has quit [Quit: Gateway shutdown]
<emersion>
keegans: ideally either fix the GitLab bug or start a BSD VM in the GitLab CI
ppascher has joined #wayland
manton has joined #wayland
manton has quit [Remote host closed the connection]
blue__penquin has quit []
xissburg has joined #wayland
xissburg has quit [Remote host closed the connection]
blue__penquin has joined #wayland
pnowack has joined #wayland
MrCooper_ has joined #wayland
MrCooper has quit [Ping timeout: 480 seconds]
mtretter has joined #wayland
<emersion>
keegans: fwiw, weston already fires a (Linux) VM in its GitLab runner
DarkTrick__ has joined #wayland
<pq>
emersion, re: no-sigbus; really nice to see that progressing.
<emersion>
:)
<emersion>
Ming Lin just sent a new version this morning
<emersion>
it works on all files, not just shm, but it's restricted to PRIVATE mappings only
adjtm has quit [Ping timeout: 481 seconds]
<pq>
private APIs... yeah, that's very much why I am so keen on locking down private APIs :-/
<emersion>
:S
<pq>
keegans, emersion, BSD VM in Gitlab CI sounds fine to me. I think it would have been done already, if there had been a suitable BSD image to run? And since then it exists now?
<emersion>
it exists yes
<emersion>
i've… tried doing it
<emersion>
but the freedesktop ci templates are too much for me
<pq>
emersion, did you try the weston approach or something else?
<emersion>
i tried reading ci-templates to see how a freebsd thing would fit
<pq>
oh right... the weston script uses virtme, which totally is not going to work here.
<emersion>
yea
<emersion>
but the part where you start qemu, i can do
<pq>
...but the weston script also does nothing with ci-templates to run qemu
<emersion>
i maintain something similar for builds.sr.ht
<emersion>
the hard part for me is integrating it properly with ci-templates
<pq>
why look into ci-templates then?
<emersion>
maybe should just give up on that
DarkTrick has quit [Ping timeout: 480 seconds]
<emersion>
to make it easy for anyone to fire up a BSD VM
<pq>
wouldn't people just run the script from the wayland repo that does it?
<gitlab-bot>
wayland issue (Merge request) 376 in weston "WIP: Synchronized popup moving" [Libweston-Desktop, Xdg_Shell And Wl_Shell, Opened]
<jadahl>
the purpose of the synchronization extension was popup repositioning
<pq>
oh, okay
<pq>
looking at the libweston.h changes, that looks suspiciously simple...
<pq>
I would have expected a graph data structure containing weston_surface_state objects
<pq>
or multiple queues with cross-links
<pq>
a client could build arbitrary chains of sync-dependencies, also to and from sync'd sub-surfaces, right?
<jadahl>
it's a different state cache sitting in the surface, applied on transaction.commit. one surface can only belong to one transaction
<jadahl>
the subsurface implementation has its own cache
<jadahl>
difference is that committing the subsurface state may commit to the transaction cache, and that acts only on transaction.commit
<pq>
but what if that transaction is pending on a sync'd subsurface's parent commit?
<pq>
that is, a sub-surface is in the transaction?
<pq>
so you can commit the transaction, but nothing will actually happen until the sub-surface's parent is committed (which was never added to the transaction)
<jadahl>
the idea is that a surface has path to "applying" active state. with subsurface, that goes through set_desync/set_sync, and the subsurface cached state, for "normal" surfaces, it goes directly from wl_surface_commit(). what the wp-transaction implementation do is add a second cache "after" whatever the subsurface does, before the "apply-to-active"
<jadahl>
so whether subsurface desync/sync/commit/parent/blabla does anything, in the end, it becomes a "apply-to-active", that now would become "apply-to-transaction-cache"
<jadahl>
so a wp-transaction implementation doesn't care about how subsurfaces do things
<pq>
you are assuming that the sub-surface cached state would be latched before the transaction cached state?
<pq>
isn't the transaction about *latching* the state of all added surfaces at the same time?
<gitlab-bot>
wayland issue (Merge request) 26 in wayland-protocols "unstable: Add surface group transaction protocol" [New Protocol, Opened]
<pq>
what if one of the transaction surfaces *cannot* latch the state when the transaction is committed?
<jadahl>
the intention is that the subsurface protocol and wp-transaction protocol works in isolation. the wp-transaction only cares about what a possible subsurface transaction finally committed
<pq>
also keep in mind that what sub-surfaces do today, we will also have gfx fences doing a similar thing
<jadahl>
committed as in what would now be "applied"
<pq>
so gfx fences will also stop the whole transcation until all surfaces in it can actually latch
<jadahl>
right, so if one looks at it like a "chain of cached state" it'd be: pending -> subsurface -> wp-transaction -> gfx-fence -> active
<pq>
special-casing sub-surfaces seems like a bad idea to me, we will have more things that will delay the latching of surface state
<jadahl>
not sure what you mean with "special casing" here. the idea is to have each "state latching/caching" to have a reasonably well defined semantics not affecting each other
<pq>
I think I'm saying that they *must* affect each other, you cannot deliver the promise of "all these updates will be latched simultaneously"
<pq>
*otherwise you cannot
<jadahl>
not sure what you mean by that
MrCooper_ is now known as MrCooper
<pq>
ok, a simple example with fences: let's have two surfaces A and B, in the same transaction, each with its own fence that have not signalled yet.
<pq>
you commit the transaction
<pq>
nothing must happen on screen, until *both* fences have signalled
<jadahl>
yes?
<pq>
How's what going to work?
<jadahl>
the way I had planned it is this:
<pq>
let's say the two fences signal 2 seconds apart
<jadahl>
client adds surface A and B to a transaction, commits their state with unfinished buffers. compositor puts this in their corresponding wp-transaction cached state.
<jadahl>
transaction is committed, compositor puts surface A and B state in a "gfx-cache"
<jadahl>
buffer of surface A becomes ready, gfix-cache marks it accordingly
<jadahl>
gfx-cache would need to be structured like the wp-transaciton cache, i.e. group surfaces together for that particular cache
<pq>
Yeah, as I was going to ask: How does gfx-cache know that when surface A fence becomes ready, it must still wait for surface B fence until it actually latches the state?
<jadahl>
buffer of surface B becomes ready, gfx-cache marks it accordingly, and it notices all relevant surfaces are ready and it can commit
<jadahl>
the "groupness" needs to be transferred some how I suppose
<gitlab-bot>
GNOME issue (Merge request) 1880 in mutter "Draft: wayland/surface: Defer applying state updates until dma-buf file descriptors are readable" [5. Performance, 5. Wayland, Opened]
<pq>
in the end, every piece of cached state has a list of "blocking things": fences, transactions, sync'd sub-surface parents
<MrCooper>
(that transaction mechanism should work for the wp_transaction protocol as well)
<jadahl>
a tree of caches sounds like something a gfx-fence implementation needs
<pq>
so I think we should model the "list of blocking things" and the "chain of updates", and then simply plug in sub-surfaces, transactions, and gfx fences into it.
<pq>
yes, sub-surface + transactions needs too
<jadahl>
pq: thats practically what I was doing, except I didn't do "gfx fence" so the implementation I did a year ago only does "chain of updates"
<jadahl>
it would need to be taught about the "dependency tree" to be able to deal with gfx fences
<pq>
jadahl, the transaction protocol spec seems to work around by saying that sync'd sub-surface's state must be applied before it's taken into account in transactions, but I think that is just special-casing sub-surfaces in a way that does not generalize to e.g. gfx fences.
<MrCooper>
FWIW, my mutter MR fully handles dependencies and can apply transactions out of order
<pq>
MrCooper, points to you I guess :-)
<MrCooper>
it handles sub-surfaces via implicit transactions as well
<jadahl>
pq: the whole point is to at least define an order. it's unavoidable
<pq>
jadahl, why?
<jadahl>
why should it be undefined?
<pq>
and what do you mean?
<pq>
let's say you have a sync'd sub-surface; latching in the committed state update should depend on everything it needs to: parent surface latching, latching the transaction commit it is part of, and its own gfx fence.
<pq>
no-one knows for sure in what order do each of those requirements signal, but it also doesn't matter - nothing must happen on screen for that sub-surface until they all have signalled.
<jadahl>
if you commit a sync subsurface of a transaction, then commit the transaction, add it to a transaction again, then commit the parent, is the applied state one including the initial subsurface state or not
<pq>
latching the sub-surface's parent surface state may be part of a *different* transaction, which then must also wait a yet another surface's gfx fence, etc.
adjtm has quit [Ping timeout: 480 seconds]
<jadahl>
i'm not talking about gfx fences here, lets pretend they are all ready in time
<pq>
jadahl, the applied state is what was committed to the sub-surface first time, because that is the *update* that was conditional on both the first transanction (already committed at that point) and parent surface state latching (which presumably happens on parent commit)
<pq>
yes, we can forget about gfx fences. It changes nothing, just makes things harder to explain. :-)
<jadahl>
as the protocol is defined now, it would not include that subsurface state
<pq>
yes, I think the protocol spec is wrong.
<pq>
it makes sub-surfaces a very special case, that does not generalize
<pq>
and if it does not generalize, we will have more difficulty in implementing gfx fences later
<pq>
it's also confusing, because sub-surface extension provides one way to postpone state application, and gfx fences offer another way to postpone state application, and they have *different* semantics
AJ_Z0 has quit [Ping timeout: 480 seconds]
<pq>
wrt. transactions, that tie multiple surfaces' updates together
<jadahl>
the fact that they have very different semantics to me is a reason to not have them poke at the same cached state and then have some "combination of commits and things" until this cached state can be finally applied
<pq>
I say they should not have different semantics to begin with. :-)
<jadahl>
they have different specifications. wp-transaciton does not have 'set_desync' or 'set_sync', a "parent" and "children"
<jadahl>
thats the semantics of subsurfaces, it doesn't apply to gfx fences or wp-transaction
<pq>
in the end, each of the sync'd sub-surface, transcation, and gfx fence just put another lock on the state update: "don't make this happen yet"
<pq>
jadahl, why is that relevant? They are all just different ways to put a "not yet" lock on an update.
<pq>
and you can't latch the update until all locks have removed
<jadahl>
aren't we talking about semantics when things get applied?
<pq>
transactions are bigger locks in that the transcation lock cannot be removed if any update in the transaction still has any other lock
<jadahl>
the semantics for subsurface involves things that doesn't existing in wp-transaction and gfx fences, so I don't know why you're saying "they shouldn't differ"
<Levans>
Do I understand correctly that what you describe pq is something like: surface states have a list of dependencies for being applied that is fixed on surface commit (gfx-fences, parent state of sync subsurfaces, etc...) and that the semantics of transaction should be "apply the cached state on all surfaces in the transaction once all of them only have the transaction remaining as a dependency" ?
<pq>
yes, I'm talking at a more general level.
<pq>
it is irrelevant on how an update lock comes to be, or what removes it. What is relevant is that it exists and can be removed.
<jadahl>
pq: fwiw, a gfx fence needs to remember a "history" of cached state, how do you deal with that?
<jadahl>
how does that fit into a single "cache"?
<pq>
Levans, yes.
<pq>
jadahl, that's my point: it doesn't.
<jadahl>
it should
<jadahl>
it must
Pharyngeal27 has joined #wayland
<pq>
that's why we need new data structures
<pq>
it can't
esh has joined #wayland
Pharyngeal27 has quit [Remote host closed the connection]
esh has quit [Remote host closed the connection]
<pq>
let's look at gfx fences alone:
<jadahl>
if you have a swap-interval-0, that draws two synchronized surfaces at 1000 fps, when page flipping, we should get the last "combined" state that happens to be ready just before vsync
<pq>
yes
<pq>
so you have to always keep the latest combined state is combined-ready, plus all the more recent individual states that are not ready yet.
<pq>
ooh, I see where you are going
<pq>
this would change the mailbox into a queue
<pq>
so that's just another complication to implement the update locks in an effcient way
<pq>
the main question there being: how do you know if you can supersede a previous state update? (as in, merge together, like we do right now with no locks and an app that updates faster than the compositor presents)
adjtm has joined #wayland
<emersion>
can't you always merge?
<pq>
without transactions, yeah, I guess, but what about with transcations?
<emersion>
what do transactions change? isn't it the same?
* MrCooper
not following what the problem is :(
* emersion
same
<pq>
jadahl, maybe your chain model would work better if it was fence lock -> sub-surface lock -> transaction lock?
<jadahl>
pq: from a protocol point of view, there is alwvays the "active" state that is what comes "after" wp-transaction/subsurface. that is the state gfx fence "queue" needs to handle
<pq>
transcations being the only one that actually controls multiple surfaces together
<pq>
and the transcation must wait until all individual surfaces are ready
<pq>
not surfaces, but the updates
<pq>
jadahl, why? You can't latch an update to screen until all locks have been lifted, so might as well handle the gfx fence first, and leave the most complicated one the last: transactions.
<pq>
^ thinking on clients that do not update more than once per refresh
<jadahl>
i mean in the case where an active state has buffers that are not ready and they can't be applied immediately
<MrCooper>
that's basically how my mutter MR works
<pq>
jadahl, what's "active state? The state on screen?
<jadahl>
active state as defined by Wayland (not gfx)
<jadahl>
what the client say is the truth
<pq>
what's the definition?
<jadahl>
today that is whats after wl_surface_commit() without subsurfaces, and wl_surface_commit(child)+wl_surface_commit(parent) with subsurfaces
<jadahl>
i.e. what a client defines as the state e.g. that is associated with a ack_configure(serial)
<pq>
The on-the-screen state cannot have unsignalled fences by definition. The on-screen-state is the current state that the compositor will operate on, wrt. e.g. input events and everything.
<jadahl>
the "active" state according to wayland is not necessarily the same as the displayed state on screen. the displayed state on screen can be an "old" "active" state
<pq>
ok, that very much sounds like on-the-screen-state
<pq>
old only in the sense that the pixels didn't turn to light yet, but it's still the state that is current from all software perspective
<jadahl>
old as in the client had since it committed that state, committed newer state
<pq>
when we add gfx fences to the picture, those fence will delay state becoming active
<pq>
well, you have a dilemma there, too
<MrCooper>
for transactions vs synced sub-surfaces, how about: If the parent surface of a synced sub-surface is part of a transaction, the cached sub-surface state at transaction commit time becomes part of the transaction, regardless of whether the sub-surface is part of the transaction
<MrCooper>
GFX fences only delay the actual presentation, not state becoming active in the protocol sense
<jadahl>
MrCooper: that'd just entangle subsurfacesand wp-transactions protocols
<pq>
will the compositor use the state as repainted to act on, or will the compositor use the state as committed by the client to act on? Currently I think compositors do the later, but nothing stops doing the former. The former would be more correct, too.
<pq>
no, gfx fences *must* delay state becoming active, not only presentation
<MrCooper>
pq: the whole Wayland state machinery is still based on the order of commits
<pq>
MrCooper, yes, I'm not breaking that.
<jadahl>
pq: in my imagined implementation, the compositor will normally act on the state committed once buffers are ready *UNLESS* various special casing involving unredirection and no *window* state changes
<MrCooper>
otherwise there can be inconsistencies
<pq>
composite-bypass optimizations are something I never even thought of yet
<MrCooper>
(or all transactions would have to be serialized?)
<pq>
all transcations do need to be serialized anyway, right? To keep the protocol message ordering like we have today.
<MrCooper>
transactions only need to be serialized if they affect the same surfaces (and maybe other entities?)
<pq>
yeah, isn't that what we're talking about?
<MrCooper>
I'm not sure TBH :)
<pq>
there is no ordering between totally independent surfaces from the same client, no.
<pq>
but both sub-surfaces and transactions create ties between updates on surfaces, so the updates on the different surfaces are no longer independent, and must retain the protocol message ordering semantics.
<pq>
we're so wildly jumping from one topic to another here before getting anywhere on even one of them :-D
<pq>
So let's jump again: what should happen, is a client repeatedly commits a new transaction with only one surface (update) part of it each time, and does this much faster than the compositor is presenting?
<pq>
*if
<MrCooper>
same thing as just repeatedly committing the surface without transactions
<pq>
yes, so that we can at least agree on. :-D
<pq>
IOW, the client puts a transaction lock on the update, the committing the transaction immediately removes the lock because the transcation depends on nothing else, and the update gets merged into the surface's active state immediately.
<Levans>
I may be missing some subtleties, but can't sub-surface cached state be flattened into a virtual transaction on commit of the parent surface? This way, the compositor could be iteratively merging these virtual transaction as the parent surfaces are committed along the sub-surface tree, and even with real transactions, so that in the end we just need to deal with transactions and gfx-fences?
<pq>
Levans, I'm not sure, would have think through several cases.
<pq>
..on paper
<MrCooper>
pq: yes, state becomes "active" in the protocol sense at surface/transaction commit time, regardless of any delays until the compositor actually makes use of that state
yari_[m] has joined #wayland
yari_[m] has quit [Remote host closed the connection]
<pq>
jadahl, btw. when I talk about gfx fences, I mean the new way of using them, not how they work right now. That is, I mean the compositor will explicitly check the fence and not make the update active until the fence is done. Just in case that wasn't clear.
<MrCooper>
Levans: my mutter MR above handles synced sub-surfaces via implicit transactions like that; haven't got around to wp-transactions on top of that
<jadahl>
right
<pq>
jadahl, I'm getting a feeling now, that your idea of a finite set of cached state slots (gfx fence not ready, sub-surface not triggered, and transaction not ready) might work when combined with the "update lock" idea. So pretty much what you explained, but transaction must be the last one, because it needs to look at updates for multiple surfaces before it acts.
<pq>
that way you don't need to let e.g. gfx fence step know about transaction dependencies at all
<pq>
so maybe the implementation does work, but we're going to need an impressive battery of tests to verify that.
<pq>
I may also be falling to the pit of underestimating how sub-surfaces should work
<jadahl>
pq: in my idea, it'd be one subsurface cache state slot, one wp-transaction state slot, and a series of gfx-fence cache slots
<jadahl>
and they know nothing about each other, except the gfx ones needs to know about other dependent ones
<pq>
why a series for gxf fences but not for the others?
<pq>
why do you want the gfx fences last?
<Levans>
jadahl: Would the subsurface cache slot also contain the associated commited state of the child sync subsurfaces then?
<jadahl>
subsurfaces are defined to have a single cached state; wp-transaction is as well
<jadahl>
Levans: the subsurface cache slot would be have 100% as it does in all the compositors that implement it
<jadahl>
pq: because it acts on what the protocols define as active (not presenteable)
<pq>
I don't understand.
adjtm has quit [Ping timeout: 482 seconds]
<jadahl>
the "ready-ness" of buffers can be amended in each cache slot, it's a state of the buffer, not the cached state
<jadahl>
and the gfx cache slot would only be used if it was reached and it needed to hold off with applying it
<pq>
Each update can effectively have just one gfx fence. Just like each update can potentially depend on at most one sub-surface parent, or one transaction.
<pq>
amended??
<jadahl>
it still needs a "queue" of inter-dependent gfx cache slots
<jadahl>
pq: whether a buffer is ready is (on a high level) a boolean state of a buffer, is it not? as in, a buffer can technically be ready before its committed
<pq>
yes
<jadahl>
thats what I mean
<jadahl>
it's a state of the buffer, not the cache slot
<jadahl>
so if its ready early, the buffer state is amended from "not ready" to "ready"
<jadahl>
a gfx-fence would look and potentially wait on that buffer state
<pq>
if the lock is already removed (fence is already signalled), it will just flush through the gfx fence state slot immediately to the next stage.
<jadahl>
right
joes has quit []
<pq>
and it will pick up whatever state from the gfx fence slot already had that's not overwrriten by the new update
<pq>
that's what sub-surfaces do too, when the update is not held by the cache
<pq>
but I think I have a feeling of the problem you refer to, it's just hard to visualize
<Levans>
Example: let's say we have (parent surface) <- (child surface) <- (grandchild surface). Now client commits (buffer 1) on (grandchild surface), then commits (child surface), then commits (buffer 2) on (grandchild surface), then commits (parent surface)
<Levans>
Hmm, sorry to ask about this, but I'm not sure I'm clear on the "subsurfaces are defined to have a single cached state" part.
<Levans>
My intuition says it should be (buffer 1) that becomes active
<pq>
a gfx fence that is not ready should not stop the update from going to further slots, e.g. the one for a transaction, because protocol.
<Levans>
But that requires 2 caches for the grandchild surface
<pq>
Levans, yes, buffer 1 hits the screen, buffer 2 is held in the grandchild state cache because its parent (child surface) didn't commit yet.
<pq>
...or that's what *should* happen
<pq>
I'm not quite sure if e.g. weston works like that. We never had tests for this.
<MrCooper>
actually, I think the protocol defines synced sub-surface state to be applied when the parent surface state is applied, not committed?
<pq>
yes
<pq>
but "which state?"
<MrCooper>
in the example, the child state is only applied when the parent state is committed
<Levans>
So, when child is committed, the grandchild cached state should be linked to the child cached state, right?
<MrCooper>
therefore buffer 2 would be applied for the grand child
<pq>
Levans, yes.
<pq>
That's what the protocol intended, at least.
<MrCooper>
not how I read the sub-surface protocol
<Levans>
OK, that's what I had in mind when I asked if the cached subsurface state should contain the cached state of the sync child subsurfaces as well...
<pq>
(I wish you'd called the surfaces A, B and C, these names are confusing as the child is a parent) :-P
<Levans>
(ah sorry for that ^^")
<pq>
MrCooper, commit on (child surface) create a new (pending) state.
<pq>
pending state is the state that is in the process of being accumulated from client requests, and something the compositor does not act on until commit on that surface.
<Levans>
But then, if a client decides to create a deep tree of sync subsurfaces, and for some reason commits them in a weird order, then a given subsurface can end up having several cached states in waiting, right?
<pq>
so grandchild committing buffer 2 kind of becomes part of the pending state on (child surface)
<pq>
Levans, yes, I think that is what it means.
<pq>
and everyone probably failed to realize that, because no-one ever tried nested sub-surfaces
<pq>
and this also the reason why I think the transactions implementation looked too simple
<pq>
...because the sub-surface state machinery is already too simple
<MrCooper>
I'd say at the very least this needs to be clarified in the sub-surface protocol, as well as the interaction between this and the transaction protocol
<pq>
yeah, probably clarified to how implementations work today, and not what the protocol intended.
<pq>
that may make nested sub-surfaces much less useful, but OTOH if that's the implementation, then no-one is using them and caring anyway.
<Levans>
The intended version would work nicely with a virtual-transaction implementation, I think. On commit, a surface creates a virtual transaction that contains its latest commited state and fuses into it the latest created virtual transactions of all of its sync children, something like that.
<MrCooper>
pq: the Doxygen comment in the client protocol header says "Synchronized mode caches the wl_surface state to be applied when the parent's state gets applied", nothing about "committed"
<pq>
Levans, yup
<pq>
MrCooper, yes. Why does that confuse you?
<MrCooper>
it means the grandchild ends up using buffer 2 :)
<pq>
MrCooper, the point is that a surface can have *several* sets of state. A new set is created on commit.
<MrCooper>
where is that defined?
<MrCooper>
anyway, gotta run, bbl
<Levans>
Current smithay implementation uses buffer 2, and I was about to start completely refactoring it so that it uses buffer 1 because I though my implementation was too simplistic... Glad I asked then ^^"
<Levans>
I thought I just had missed the consensus, looks like it's not that consensual...
tzafrir has quit [Ping timeout: 480 seconds]
verlet64_ has joined #wayland
verlet64_ has quit [Remote host closed the connection]
<jadahl>
pq: the transaction weston implementation I guess is just as naive as the subsurface and doesn't handle a series of cached state. i.e. in weston today there is only the pending (pre-commit) and cached (post-sync-subsurface-commit) and active state, AFAICS
<jadahl>
a more correct subsurface implementation would keep the cached state on the parent, but that's not how it seems to work
<jadahl>
but the wp-transaction implementation is correct, I think, except for the grand child issue, as it is defined to act on the state applied *after* subsufrace synchronization has taken place. i.e. it means the implementation is potentially quite small.
<jadahl>
of course that ignores gfx fences which would complicate things, but there is no such thing in weston
<jadahl>
imo it brings an argument why subsurface and wp-transaction should keep separate cached state and have a defined order
<Levans>
It seems to me that an approach sur subsurfaces using virtual-transactions merged into each other and into real transactions would end up just producing a stream of transaction, each with its set of blocking fences, that the compositor would then just apply in order as they become ready.
<Levans>
There are probably details I'm missing, but that seems pretty well-defined semantics to me.
<pq>
MrCooper, wl_surface.commit is defined to copy pending state to "the surface state" or so. So it's an explicit transition step.
<pq>
MrCooper, sub-surface state, after committed on the sub-surface, essentially should become part of the parent surface pending state. That is what it has to be to achieve what the sync'd sub-surface is supposed to: synchronize with the parent surface on screen.
<pq>
MrCooper, but the protocol was written in different words (by me), and I think I failed to both communicate that and to think through how it should work with nested sub-surfaces.
<pq>
If you think about the counter example with three surfaces, parent, child and grandchild, and each of them updates its own state plus its child's state, you see that several different states must emerge or the synchronization breaks.
<pq>
Let's call the root surface A, the child surface B, and the grandchild C.
<pq>
The synchronized sub-surface idea is that each surface must ack its sync'd child surface state.
<pq>
So if a commit on C can ever become visible without a commit on B *after* that commit on C, the synchronization is broken.
<pq>
Things work totally fine if sub-surfaces are never nested. But if they are nested, I think me and everyone failed to cater for the corner cases.
<pq>
jadahl, exactly.
Drakulix has joined #wayland
Drakulix has quit [Remote host closed the connection]
<MrCooper>
pq: yeah, I've come to agree with you :) my reading of the semantics would make the term "synchronized" meaningless for grandchildren
<MrCooper>
in my defence, I just applied the rule I quoted recursively: pending state for C is applied when pending state is applied for B is applied when pending state for A is applied, which is when A is committed
modin has joined #wayland
<pq>
MrCooper, yeah. The intention got lost somewhere in the translation to spec and code. :-)
<Levans>
So, I've tried to formalize the intuition of virtual-transactions into an algorithm, which I think make the whole subsurface/transactions/fences thing well defined. I have written it here: https://gist.github.com/vberger/b8a48fb0f225431c3a2d4c5d2fd81344
<pq>
I could also kick myself for not writing extensive tests, but that was also a bit difficult as the screenshot facility for weston tests came maybe a fwe years later.
<Levans>
Does that seem relevant?
<MrCooper>
I think this highlights that the transaction protocol needs to be more specific about the interaction with sub-surfaces; in particular when a synchronized surface is part of a transaction, but not its parent
p_swizzles has joined #wayland
p_swizzles has quit [Read error: Connection reset by peer]
<pq>
MrCooper, btw. is it already clear what should happen with a sync'd sub-surface when the parent surface is part of a transaction? Logically it's obvious, right? But do spec agree?
<jadahl>
MrCooper: wp-transaction is quite clear, it states that the surface state of a surface that comes out of a subsurface "transaction", or if not a synchronized subsurface, out of wl_surface_commit(), is what is the "input" to the wp-transaction
<MrCooper>
not sure; there could be interesting corner cases, e.g. if both are part of a transaction, but the child is committed again after the parent but before the transaction commit
<pq>
Levans, I've been using the word "update" for the state delta, FWIW.
<MrCooper>
Levans: your description basically matches what I intended for my mutter MR, the implementation just doesn't fully match yet due to my mis-reading of the sub-surface semantics
blue__penquin has quit []
<MrCooper>
jadahl: I'm sure it's clear to you :) I'm still struggling to grasp what it actually means in specific cases
<pq>
I think we're going to need a diagram of a surface with its different state slots, starting with pending, current, presented. Currently presented state is not tracked nor used, but I think it's needed in discussion. Well, presentation time does track it with presented/discarded events.
<jadahl>
gitlab supports state diagram via ```[format]```. maybe it can be utilized for this
<keegans>
once the FBSD CI MR you have is merged, i'll follow up with OBSD as well
<Levans>
<pq "Levans, I've been using the word"> Ok, I'll use that as well then.
<emersion>
keegans: yup, looks good. btw, any reason why you can't use epoll-shim?
<pq>
Levans, we are kind of lacking vocabulary too. "update" may or may not have been used on protocol spec.
<pq>
the different surface state slots almost have consistent names in specs I think
<pq>
then things like commit/apply/latch state are more vague
<emersion>
keegans: i can't guarantee we'll support anything other than the epoll API, because it'd be a lot of work and maintenance burden
<emersion>
we're already not too happy about having to maintain an event loop API
<MrCooper>
mutter uses "update" for the process of presenting a frame
<emersion>
so trying not to expand its scope here
<Levans>
MrCooper: ok, so we are on the same understanding wrt the transaction algorithm, cool.
<Levans>
But this does not match jadahl's proposal, if I understand correctly?
<keegans>
emersion: hmm, I see. would you be open to replacing the epoll API with an event loop that someone else can maintain, say libev or libuv?
<MrCooper>
it could be equivalent, honestly not sure
<emersion>
keegans: just to be clear, the reason is not that we don't want OpenBSD support. just that it was a mistake to use epoll, we should've used a library instead
blue__penquin has joined #wayland
<emersion>
i'd personally be open to that, but we need to make sure we can provide a 100% backwards compatible ABI
<emersion>
and there are a lot of tricky details in there
<keegans>
yeah that is my concern with epoll-shim, my understanding is that openbsd is not as friendly towards shimming, and my MR also ports Wayland to macOS
<keegans>
so I am happy to switch gears and start experimenting with implementing libuv without breaking ABI
<emersion>
pq ^
<emersion>
there are a lot of implicit ABI details, like the exact order in which wl_event_loop sources fire
<emersion>
idle sources, etc
<pq>
Levans, that is a good write-up. I'm just not sure we can or should change the sub-surface behavior to match the write-up.
<emersion>
keegans: maybe start by creating an issue for it? i guess the first step would be to make sure it's possible with libwayland's public ABI, and see what the available libraries are
<pq>
Levans, your write-up sounds like my ideal goal.
blue__penquin has quit []
<keegans>
emersion: sounds good. i'll take a look tonight
<emersion>
cool, thanks :)
blue__penquin has joined #wayland
<pq>
keegans, emersion, sounds good to me to investigate at least.
<Levans>
pq, thanks. This write-up matches what I had understood to be the specified behavior of subsurfaces. So I guess the subsurface spec will need to be clarified in all cases, if different persons interpret it in different way.
<pq>
keegans, emersion, another path would be to slowly deprecate the whole event loop API from libwayland-server. If no-one uses it, it doesn't need an implementation.
<emersion>
hm
<emersion>
do we have a clear picture who the users are?
<pq>
veeery slow
<emersion>
weston, everything wlroots, who else?
<pq>
all Wayland compositors, given that you can't pull client fds out of it yet.
<emersion>
would could start by deprecating wl_event_source_add_*
AJ_Z0 has joined #wayland
<emersion>
we could*
<pq>
yeah
<Levans>
In Smthay & Rust we use our own event loop abstraction for all FDs other than the ones from wayland, and if it was possible to treat each client source independently, we would do so
<Levans>
Smithay*
<Levans>
(But well, we're not exactly major players :P)
<pq>
I recall hearing that Mutter already uses the bare minimum it can of the event loop API
<emersion>
i'd assume KDE as well, since everything there probably uses Qt's event loop
<JPEW>
Would any nested compositors or custom embedded compositors be using that?
<pq>
JPEW, the same as everyone else: up to them to choose between "full use" and "just to server Wayland clients and listening sockets"
<pq>
*serve
<pq>
We wouldn't remove the code from libwayland-server, but migrating away from it would allow running things on *BSD.
<pq>
then *BSD would not need an implementation of the libwayland-server event loop API, nor an epoll shim
<pq>
IOW, everything would keep on running at least as well as it does today
<pq>
getting some BSD in CI is still a good idea regardless
<keegans>
yeah, i think let's get the fbsd ci and obsd ci in. then i'll see if another event loop is a dead end or potentially good idea, and if not we can discuss deprecating the evloop (maybe not in that order idk)
<emersion>
keegans: out of curiosity, is it impossible to get epoll-shim on Darwin?
<keegans>
it doesn't say it's supported, but i haven't tried. i'll see now
<keegans>
heh yeah, that's not going to build without some legwork 😓
<keegans>
also fwiw, poll is completely broken on darwin and has been broken for at least back until 10.12
<keegans>
"The UNIX 03 Product Standard is a precisely defined and documented set of functionality to which products can be certified. It provides a mapping between certification, the specifications, and the test suites needed to demonstrate conformance. "
<keegans>
so obviously their test suite is not very robust ...
benbrown has joined #wayland
rails[m] has joined #wayland
_whitelogger has joined #wayland
tagr has joined #wayland
chasmo77 has joined #wayland
chasmo77 has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-04 14:33:56)]
shankaru1 has quit []
feaneron is now known as Guest859
Guest859 is now known as feaneron
tomke has joined #wayland
<tomke>
hi
<tomke>
we spoke ages ago about the alpha cut-out
<tomke>
for hardware platforms with video underlay
<tomke>
I've sent 2 merge requests just now
<tomke>
one for wayland-protocols with the (trivial) protocol
<tomke>
and one for weston with a (equally trivial) implementation in the gl-renderer
<tomke>
please let me know if this is something you'd be interested in
<tomke>
the weston change requires the wayland-protocols change
<tomke>
is there a way to specify this dependency?
blue_penquin is now known as Guest865
vmesons has quit [Read error: Connection reset by peer]
vmesons has joined #wayland
bodiccea_ has joined #wayland
bodiccea has quit [Ping timeout: 480 seconds]
Sumera[m] has quit []
Sumera[m] has joined #wayland
khfeng has joined #wayland
blue__penquin has quit []
rgallaispou2 has quit [Read error: Connection reset by peer]
Arnavion has quit [Remote host closed the connection]
Arnavion has joined #wayland
khfeng has quit [Ping timeout: 480 seconds]
leah221 has joined #wayland
leah221 has quit [Remote host closed the connection]
pastly-antispam has quit [Quit: time for a tune up]
pastly-antispam has joined #wayland
vmesons has quit [Remote host closed the connection]
Blablubber has joined #wayland
Blablubber has quit [Remote host closed the connection]
enilflah has quit [Ping timeout: 480 seconds]
DivideBy0x0 has joined #wayland
DivideBy0x0 has quit [Remote host closed the connection]
pastly-antispam has quit [Remote host closed the connection]
JanAinali[m] has joined #wayland
JanAinali[m] has quit [autokilled: This host has violated network policy. Contact support@oftc.net with questions (2021-06-04 20:36:12)]
pastly-antispam has joined #wayland
reillybrogan has joined #wayland
st3r4g has joined #wayland
elmcrest has joined #wayland
elmcrest has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-04 20:54:01)]
tkerby has joined #wayland
tkerby has quit [Remote host closed the connection]
danvet has quit [Ping timeout: 480 seconds]
ajax has quit [Ping timeout: 480 seconds]
ParAd0x^ has joined #wayland
ParAd0x^ has quit [autokilled: spambot. Dont mail support@oftc.net with questions (2021-06-04 22:18:26)]
Prf_Jakob has joined #wayland
neonking has quit [Remote host closed the connection]
st3r4g has quit [Quit: おやすみ]
jnny has joined #wayland
rawoul has joined #wayland
jnny has quit [Remote host closed the connection]
floof58 has quit []
floof58 has joined #wayland
hardening has quit [Ping timeout: 480 seconds]
linuxdaemon14 has joined #wayland
linuxdaemon14 has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-04 23:47:51)]