ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<Company>
I don't mind using file descriptors (well, I do mind a bit as long as we limit them to 1024 per process)
<Company>
I do mind requiring applications having to write complex code to use them
<Company>
I also do mind every wayland protocol using fds differently for basically the same thing: sending a bunch of bytes between processes
<Company>
so you can't have a good abstraction, but instead have to implement a slightly different 100 lines of code each time
columbarius has joined #wayland
<Company>
dnd/clipboard basically wants a pipe, but this one wants a memfd - but we can't spec a memfd, we instead want "must be readable and seekable and is defined by sending the offset"
co1umbarius has quit [Ping timeout: 480 seconds]
<Company>
and then you have to define tons of special error conditions because all the fds are different and who knows what kind of error the other side is gonna get from reading a random fd
<kennylevinsen>
Company: just use your existing allocation for wl_shm purposes
<kennylevinsen>
the requirements are the same, no new code needed
<Company>
no worries, GTK has at least 2 copy/pasted (different) implementations of memfd usage
<kennylevinsen>
the wording is a bit awkward, basically just wants to say "should work with mmap and pread" - not sure why you'd ever want to read instead of mmap, but whatever
<Company>
one using memfd_create() and the other syscall (__NR_memfd_create,...)
<kennylevinsen>
well maybe there's room for some cleanup, but it seems like you have all the code you need already then
<Company>
I guess the old one is whatever krh wrote when he invented the wayland backend and the new one is a copy form mutter or weston
<Company>
my point is less about my ability to write that code
<Company>
it's about the unnecessary complexity and forward maintenance
<kennylevinsen>
you can feel that way, but I just can't agree. fd's are needed for efficiency and seem like en entirely reasonable unix-idiomatic design choice...
<Company>
I did not complain about using fds
<kennylevinsen>
correction, mmapable fds
<Company>
the icc profile code definitely doesn't need mmapable fds
<Company>
nobody is gonna throw gigabytes per second of icc profile data at a compositor
<kennylevinsen>
i definitely would not want to waste time in a copy loop of large data structures on both ends when it is trivially avoided by just mmapping
<kennylevinsen>
The same reason that keymaps are strictly declared to be mmapable
<ascent12>
For a unix program, making a shm file is not weird/complex at all.
<ascent12>
I think the protocol buffer was like 4KiB or somewhere around that. sending an icc profile literally could be too big for it
RAOF has quit [Remote host closed the connection]
RAOF has joined #wayland
sevz has joined #wayland
nerdopolis has joined #wayland
carlos_ has quit [Ping timeout: 480 seconds]
ANDROID_IOS_user has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
ANDROID_IOS_user_ has joined #wayland
ANDROID_IOS_user has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
ANDROID_IOS_user__ has joined #wayland
ANDROID_IOS_user_ has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
cvmn has joined #wayland
cvmn has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
ANDROID_IOS_user__ has quit []
ANDROID_IOS_user__ has joined #wayland
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #wayland
sima has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
gspbirel568734088670613144 has quit [Ping timeout: 480 seconds]
mblenc1 has quit [Ping timeout: 480 seconds]
Guest268 is now known as go4godvin
sevz has quit [Quit: WeeChat 4.0.4]
ANDROID_IOS_user__ has quit [Remote host closed the connection]
gspbirel568734088670613144 has joined #wayland
ANDROID_IOS_user__ has joined #wayland
tzimmermann has joined #wayland
tzimmermann has quit []
tzimmermann has joined #wayland
ANDROID_IOS_user__ has quit [Remote host closed the connection]
<MrCooper>
zzag: the way I like to think about it is: committing the parent of a synchronized sub-surface creates/amends an implicit transaction with the pending state of the parent and the cached state of the child; if the parent is itself a synchronized sub-surface, this transaction becomes its cached state
<MrCooper>
zzag: in your example, committing C results in the cached state of C being a transaction with state for C and/or D; this transaction doesn't get committed before B is committed (which results in a transaction with state for B and/or C and/or D) and then A is committed (which commits a transaction with state for A and/or B and/or C and/or D)
<MrCooper>
zzag: the transaction committed when committing A then isn't applied until all buffers attached in it for A/B/C/D have become idle)
<zzag>
MrCooper: okay thanks, that answers my question
<MrCooper>
zzag: notice how this may result in 3 independent transactions for cached sub-surface state in your example, so a single per-surface "lock" for cached sub-surface state cannot handle this correctly
iomari892 has joined #wayland
ANDROID_IOS_user has joined #wayland
<MrCooper>
zzag: also note that the only mutter-specific part is waiting for buffers to become idle, otherwise this is a general description of how synchronized sub-surfaces work
rasterman has joined #wayland
<zzag>
MrCooper: yeah, I've been just wondering what other surfaces mutter locks. Locking child subsurfaces is unnecessary though, right?
<zzag>
i.e. it should be enough to just lock all sync ancestor parent surfaces?
<MrCooper>
per above, it's unavoidable
<MrCooper>
the cached state of a synchronized sub-surface is "locked" until its parent is committed
<MrCooper>
hmm, it might be clearer to say "state changes" instead of just state for all of the above
<MrCooper>
attaching a buffer being one example of a state change
<zzag>
sure. what I meant is that parent state cannot be applied until one of its descendant subsurfaces doesn't have idle buffer
dcz_ has joined #wayland
<zzag>
locking descendant subsurfaces might be redundant because their state will be applied when parent state is applied
<zzag>
although I guess it depends on how subsurfaces are implemented
<MrCooper>
not sure what you mean by that; all buffers attached in an implicit transaction resulting from recursive synchronized sub-surface commits have to become idle before the transaction can be applied
<zzag>
i.e. whether transactions are reused to implement cached state
leon-anavi has joined #wayland
<MrCooper>
I'm afraid it sounds like you still haven't fully grokked the above description :)
<MrCooper>
the implicit transaction for cached sub-surface state is reused until the parent surface is committed, at which point it becomes part of the parent's cached state (if the parent is itself a synchronized sub-surface)
<MrCooper>
then the next commit of the original sub-surface creates a new implicit transaction for its cached state
<MrCooper>
this principle repeats recursively with nested synchronized sub-surfaces
<zzag>
MrCooper: I got that. I was talking about the general principal that the parent state cannot be applied until one of its sync subsurfaces doesn't have idle buffer and locking child subsurfaces is unnecessary
<zzag>
either way, thank you for clarifying how mutter handles it
<MrCooper>
s/one/all/
<zzag>
yeah, sorry for the typo
<zzag>
also s/doesn't/don't/ :p
<MrCooper>
"locking" for synchronized sub-surface state and for buffers not being idle is independent, can't skip one for the other
<MrCooper>
and a single per-surface "lock" for synchronized sub-surface state can't work correctly with nested synchronized sub-surfaces
<MrCooper>
no way around keeping track of the implicit transactions
<zzag>
why? parent surface won't apply new state and thus no sub-surfaces will be committed
<zzag>
s/will be committed/apply new state either/
<MrCooper>
committing sub-surfaces creates new implicit transactions though
<MrCooper>
which are independent of the committed transaction which is "locked" by buffers not being idle yet
<zzag>
MrCooper: yep, that's what I mean by not applying parent state until all its subsurfaces have idle buffers
<MrCooper>
that is true, doesn't reduce the overall complexity though
mblenc has joined #wayland
<pq>
kennylevinsen, pread'ing an fd avoids the SIGBUS horrors of mmap, when it happens to be feasible.
<pq>
kennylevinsen, also pread can be done O_NONBLOCK - poll for readable after EAGAIN, unlike mmap access.
<ascent12>
The client could give you an fd that doesn't work with poll though
<ascent12>
I assume memfds/shm doesn't work with poll
<pq>
I assume they'd never block either
<ascent12>
I've written hack clients that pass a reference to a normal file before, which worked
<ascent12>
The more I think about it, preading it maybe isn't too bad of an idea
<kennylevinsen>
my wallpaper and lockscreen clients pass bitmap files directly off the disk too
<kennylevinsen>
pq: yeah SIGBUS kinda sucks but we're not avoiding that any time soon
<pq>
zzag, how about an example on your A -> B -> C -> D sync'd subsurface chain: update D1, update C1, update D2, update B1, update D3, update C2, update D4, update A1. What states should be current after all that?
<ascent12>
I'm trying to think if OpenGL has a way you can pread it into a buffer without an extra copy. Vulkan doesn't seem like it would be hard.
ANDROID_IOS_user has quit [Ping timeout: 480 seconds]
<pq>
kennylevinsen, I am avoiding it, by intending to use pread for ICC files :-)
<kennylevinsen>
I definitely wouldn't want to spec our way out of being able to mmap, copy loops in the compositor (bloody xwayland copy/paste integration) gets me irrationally upset :P
<pq>
and passing files straight from disk of course works, but it causes a risk for the compositor that reading the file (pread or mmap) might block for a bit.
<kennylevinsen>
if you parse it streaming with pread that's fine by me
<pq>
kennylevinsen, I'm definitely keeping the requirement to be able to mmap, yes.
<pq>
we also limit ICC files to 4 MB in the protocol, which I think is fine for Weston to allocate and copy, as long as fd access does not block.
<pq>
it's just definitely too much to push as bulk data through the Wayland socket
<pq>
ascent12, um, what does OpenGL or Vulkan have to do with ICC files?
<ascent12>
I was just thinking about sharing data in general, i.e. wl_shm
<zzag>
pq: A1 -> B1 -> C1 -> D1
<pq>
this is very specificly about ICC files
<kennylevinsen>
pq: even the smallest of wayland messages are too much for the Wayland socket with high-speed input devices :)
fmuellner has joined #wayland
<pq>
zzag, right, I think. If you think about all the pending transactions between all the surfaces, I think you should find that you need to have transaction objects rather than looking at current and pending state on each surface, when further commits happen on arbitrary surfaces.
<kennylevinsen>
(that whole discussion was mostly about the client not being able to use a pipe being perceived as complexity. Even if not mmap'd you'd want to use pread anyway.)
<pq>
zzag, e.g. continue with: commit C, commit B, commit A; what is the current state on D?
<pq>
oh, I didn't understand someone wanted to use a pipe.
<pq>
for ICC files
<kennylevinsen>
yeah, the issue was with the seekable requirement and anonymous files being perceived as a resulting "unnecessary complexity" (quotes not to be rude, just to quote the opinion)
<pq>
we could do that instead of mmappable for ICC files, sure, but then you need the client to run a pipe writing loop and preferably not block itself completely on that.
<pq>
vs. just prepping a file, sending that over, and waiting for the event to say "ready"
<pq>
sure, copy/paste/dnd need that, but why would that be re-usable, if one can't make an anon file creation re-usable...
<pq>
just put the helpers in the toolkits you want your devs to use
<kennylevinsen>
even for in-memory profiles (something decoded from a compressed image file perhaps?), making an anonymous file seem pretty trivial and Gtk (the toolkit in question) would already have the code for wl_shm reasons :S
<pq>
yeah
CodeSpelunker has joined #wayland
<pq>
maybe not exposed in a re-usable form, but that shouldn't be a problem to refactor
<MrCooper>
pq: the term "current state" is a bit ambiguous though; it makes me think of the committed protocol state, whereas you meant the output state — maybe "applied state"?
andyrtr has joined #wayland
CodeSpelunker has quit [Quit: CodeSpelunker]
<pq>
MrCooper, the state currently used the compositor for display and window management. Applied, yes.
<MrCooper>
for display, right, though window management is a bit more complicated; e.g. protocol errors due to "wrong surface size" need to be based on the current committed protocol state, otherwise there may be spurious errors if a transaction gets delayed
<MrCooper>
(you probably knew this, hope it may be useful for others though)
<pq>
good point
glisse has quit [Remote host closed the connection]
glisse has joined #wayland
<zzag>
pq: A2 -> B2 -> C2 -> D3 if I understand your question correctly
<pq>
zzag, you're making me do the same exercise with pencil and paper - fair :-)
<zzag>
switching between sync and desync mode is another tricky place
<zzag>
but if the compositor tracks which state to apply when it's manageable, but still, would be nice if you didn't have to care about that case :p
iomari891 has joined #wayland
dri-logg1r has joined #wayland
<pq>
I counted A2, B2, C2, D4, meaning that D2 and D3 ended up being discarded.
dri-logger has quit [Ping timeout: 480 seconds]
iomari892 has quit [Ping timeout: 480 seconds]
<pq>
yeah, the relatively simple rules produce surprisingly complex tracking. I didn't foresee that, and I think Weston gets it wrong.
<zzag>
Oh, right. I counted C2 as the starting point for some reason
<zzag>
If you meant a new commit, then
<zzag>
A2 -> B2 -> C3 -> D4
<pq>
ah, yes
<pq>
I think it is possible at every "level" A, B, C, D to have a different state for D as a pending transaction. That's what I was trying to show.
<pq>
then depending the following commits, any one of those could end up on screen
<pq>
e.g. in that example, D3 state gets discarded by a commit to C
<pq>
discarding a transaction means sending presentation-time discarded event if one was requested
<zzag>
I don't think that it can be discarded
<zzag>
D3 and D4 would have to be merged
<pq>
ok, bad choice of words, merged, yes
<pq>
but it's still the presentation-time discarded event, because the frame is guaranteed to never show, even if the other state accumulates
lbia has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
Company has joined #wayland
kts has joined #wayland
lbia has joined #wayland
TheCatCollective has joined #wayland
nerdopolis has joined #wayland
<pq>
swick[m], I'm tempted to ask Simon Thompson which function he takes as the sRGB EOTF :-p
<swick[m]>
do it!
<pq>
lol
<swick[m]>
hilarity will ensue
<swick[m]>
pq: btw, I'm in the colorweb CG now so if you want to raise ant particular issue just let me know
<pq>
ooh, cool!
<pq>
swick[m], btw. will you take over the HDR static metadata correspondence, or should I formulate the follow-up question?
<pq>
hmm, maybe I should also ask Thompson about HLG vs. target color volume
<pq>
since he just explained how target dynamic range is a non-issue
kts has quit [Ping timeout: 480 seconds]
<swick[m]>
pq: I'm not sure when I have time. Busy with some other stuff right now.
<swick[m]>
so if you find the time, go ahead, otherwise I'll do maybe in a few days
kts has joined #wayland
<pq>
I'm might not, I'm not sure what else we could learn
<pq>
at least now we know what we don't know
<pq>
We should have a PLUGE fullscreen app.
<JEEB>
hehe, the definition of srgb eotf still being a question I see 8)
<JEEB>
hlg apparently got some imaging version being defined. only saw it in passimg in jvet documents, but no difference of definiton
<JEEB>
or well, not no difference but rather "mentiomed but definition was not explained"
<pq>
JEEB, I've made my mind based on Troy Sobotka telling me to RTFspec, but I'm curious what professionals think. :-)
nerdopolis has quit [Ping timeout: 480 seconds]
<JEEB>
:)
<pq>
I still need to reply to Troy in Gitlab
<pq>
I wonder if we'd need direct control of limited quantization range values in the video signal to properly implement PLUGE though...
<pq>
that's not really possible with KMS today
<pq>
not without sending full range and forcing a monitor to take it as limited range, ugh
<swick[m]>
which would not be a problem if we had colorops on the CRTC and separated the signalling completely from the colorops
kts_ has joined #wayland
<pq>
:-)
<swick[m]>
but yeah, right now, not so much
nerdopolis has joined #wayland
kts_ has quit []
kts has quit [Ping timeout: 480 seconds]
lbia has quit [Remote host closed the connection]
lbia has joined #wayland
TheCatCollective has quit [Quit: The Lounge - hosted by mouses.xyz]