ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
fmuellner_ has quit []
fmuellner has joined #wayland
ahmadraniri[m] has joined #wayland
akallabeth[m]1 has joined #wayland
ambasta[m] has joined #wayland
ammen99[m] has joined #wayland
AndrewAylett[m] has joined #wayland
anomalous_creator[m] has joined #wayland
apol[m] has joined #wayland
arichardson[m] has joined #wayland
azizLIGHT has joined #wayland
basemale has joined #wayland
bbaovanc[envs][m] has joined #wayland
bdaase[m] has joined #wayland
botiapa[m] has joined #wayland
Naruto[m] has joined #wayland
cmeissl[m] has joined #wayland
O5KV5980 has quit [Ping timeout: 480 seconds]
Coelacanthus[m] has joined #wayland
cousinofthor[m] has joined #wayland
d_ed[m] has joined #wayland
danburd[m] has joined #wayland
dani-g5x[m]1 has joined #wayland
davidre has joined #wayland
Nico has joined #wayland
deknos82[m] has joined #wayland
Guest3646 has joined #wayland
diamondburned[m] has joined #wayland
DrNick has joined #wayland
doras has joined #wayland
drakulix[m] has joined #wayland
elinor has joined #wayland
emilio[m] has joined #wayland
fallenchromium[m] has joined #wayland
FbioPacheco[m] has joined #wayland
Guest3656 has joined #wayland
[old]freshgumbubbles[m] has joined #wayland
furyishere[m] has joined #wayland
general_j[m] has joined #wayland
na[m] has joined #wayland
gnustomp[m] has joined #wayland
Guest3644 has joined #wayland
GrahamPerrin[m] has joined #wayland
hariselldon[m] has joined #wayland
Harvey[m] has joined #wayland
hch12907 has joined #wayland
Bran[m] has joined #wayland
heeen[m] has joined #wayland
heftig has joined #wayland
hex[m]1 has joined #wayland
idkrn[m] has joined #wayland
zebrag[m] has joined #wayland
j-james[m] has joined #wayland
japchae[m] has joined #wayland
jelmer has joined #wayland
Kelseyjgilbert[m] has joined #wayland
junglerobba[m] has joined #wayland
joantorres[m] has joined #wayland
JosExpsito[m] has joined #wayland
jryans has joined #wayland
madhavpcm has joined #wayland
mboudr35[m] has joined #wayland
Mershl[m] has joined #wayland
nazarewk[m] has joined #wayland
neobrain[m] has joined #wayland
NepNepdmsalwaysopen[m] has joined #wayland
niecoinny[m] has joined #wayland
nielsdg has joined #wayland
ongy[m] has joined #wayland
teh1[m] has joined #wayland
pac85[m] has joined #wayland
pobthebuilder[m] has joined #wayland
Poly[m] has joined #wayland
KingoftheElves[m] has joined #wayland
psydroid[m] has joined #wayland
q234rty has joined #wayland
q234rty[m][m] has joined #wayland
qaqland[m] has joined #wayland
rails[m] has joined #wayland
rajveermalviya[m] has joined #wayland
robertmader[m] has joined #wayland
RomanGilg[m] has joined #wayland
rubo_[m] has joined #wayland
Ryhon[m] has joined #wayland
Saijin_Naib[m] has joined #wayland
sewn has joined #wayland
Shimmy[m] has joined #wayland
sergi has joined #wayland
Sumera[m] has joined #wayland
swick[m] has joined #wayland
sythemeta847[m] has joined #wayland
Nova[m] has joined #wayland
lyasm[m] has joined #wayland
underpantsgnome[m] has joined #wayland
ttancos[m] has joined #wayland
tzx[m] has joined #wayland
ujineli[m] has joined #wayland
unix-supremacist[m] has joined #wayland
Vanfanel has joined #wayland
varlad[m] has joined #wayland
vchernin[m] has joined #wayland
MatrixTravelerbot[m]1 has joined #wayland
windowsxp[m] has joined #wayland
xerpi[m] has joined #wayland
YaLTeR[m] has joined #wayland
yshui` has joined #wayland
zaibon[m] has joined #wayland
zzxyb[m] has joined #wayland
nehsou^ has quit [Remote host closed the connection]
jmdaemon has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
navi has quit [Quit: WeeChat 3.8]
Brainium has quit [Quit: Konversation terminated!]
<pq>
swick[m], I want to concentrate on the Weston side a bit, and using libdisplay-info for color. I feel I need a break from *driving* protocol design.
<swick[m]>
not waiting on anything right now
<pq>
cool, as I've kinda lost track :-)
<swick[m]>
still pondering the whole luminance anchoring stuff but that's basically everything
<pq>
yeah
<swick[m]>
the feedback mechanism can be added in version 2 easily
<swick[m]>
clarification on the mastering display stuff is blocked
<swick[m]>
from my pov everything is in a state that it could be implemented and potentially merged
<pq>
I have the same feeling.
<pq>
implemented yes, not sure about merging quite as is
<pq>
The plan for weston is to copy the XML and prefix all interface names to avoid conflicts with the final form.
caveman has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
<daniels>
hmm, can someone remind me if attach/damage/commit -> damage/commit is supposed to provoke repaint with the same buffer? or do we need attach/damage/commit -> attach(same)/damage/commit?
<emersion>
i'm not sure it's clearly defined
<emersion>
in general front-buffer rendering is not clearly defined iirc
<emersion>
wlroots will repaint in both cases
<emersion>
i believe (haven't checked)
<emersion>
hmmm
<emersion>
except it might not invalidate the GL texture…
<emersion>
(it will re-upload shm buffers though)
<emersion>
the last time we discussed this was in the context of the tearing proto iirc
<pq>
daniels, if the wl_buffer was released in between, the compositor cannot re-read it.
<pq>
unless it is explicitly re-attached
<emersion>
ah, so this isn't about front-buffer rendering?
* emersion
jumped the gun a bit
<emersion>
shm with early release?
<pq>
it could be, if the compositor didn't release
<pq>
yeah
<pq>
both
<pq>
but given that a compositor *might* release in between, any client using damage+commit without attach is provoking undefined behavior
<zubzub>
if the compositor releases the buffer, then the surface has no buffer attached anymore and the surface is no longer painted no?
<pq>
you can do front-buffer rendering "just fine" if you attach every commit, right? So front-buffer rendering is no excuse to not attach.
<pq>
zubzub, no. If the compositor releases the buffer, it means the compositor retains the contents some other way. Like as a copy in a GL texture.
<zubzub>
right
<pq>
the contents are on the wl_surface, and whether the compositor needs to hold the wl_buffer is just a detail of it
<zubzub>
yeah the compositor can't decide what the contents of a surface are
<emersion>
pq, though front-buffer rendering without release violates the spec
<pq>
yes, but clients can get away with it
<emersion>
so it means the compositor is free to not update the surface contents in that case
<pq>
hence the quotes around "just fine"
<emersion>
okay, the meaning of the quotes were not clear to me
<emersion>
:P
<emersion>
i agree that attaching is a good thing to do anyways
<kennylevinsen>
hmm, I really should at some point look at my "buffer/damage validation" server project again
<pq>
daniels, me and emersion agree :-o
Guest3644 is now known as go4godvin
<emersion>
tbh i don't know how you get that idea that we always disagree from ;_;
<daniels>
haha, so the conclusion is that attach is required?
<emersion>
from my pov, we agree more often than we disagree
<pq>
attach is required if a client wants it to work
<daniels>
(the context for this is doing a bunch of dirty tracking etc within Weston, not working on some wild exotic new protocol everyone's going to love)
<daniels>
kk
<daniels>
btw, https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1281 is a pretty trivial QoL improvement if anyone's interested - unfortunately there is still a race-induced leak in drm-smoke - we can try to tear down with page_flip_pending and don't wait around long enough for the destroy, in which case we leak the output
<pH5>
daniels: wl_surface::damage(_buffer) both explicitly refer to the "pending buffer" and wl_surface::attach states that there is no pending buffer after commit. so expecting wl_surface::commit to applying damage to the already committed buffer instead of the non-existent pending buffer seems wrong, even if the behaviour in that case is not well defined.
<daniels>
leandrohrb5: ^ did you have something which fixed that or was that stuck behind other stuff?
<daniels>
pH5: wow, someone who reads the spec more thoroughly than pq :) that sounds very clear to me, thanks!
<pq>
emersion, negative things are easier to remember so there is that bias. Also if you don't say that you agree to something I've argued, I won't know that you agree.
<emersion>
yeah, true
<pq>
...I hope I say when I agree.
<emersion>
pH5: maybe there should be a protocol error for damaging without attaching a new buffer then…
<emersion>
i should try to speak up more when i do agree
<daniels>
pq: damn, all this time I've been assuming that you completely agree with me when you say nothing :(
<daniels>
(for clarity, the above is a joke)
<ManMower>
an especially useful paradigm when pq is on vacation
<emersion>
:D
<daniels>
can't wait to re-do colour management in a couple of weeks then
<pq>
Usually silence from me means: I can't bother to study enough to make my mind, or I don't want to get involved. Or maybe I never noticed the question.
<pq>
four weeks!
<pq>
you'll have free reign after four weeks, for three weeks :-)
<pq>
emersion, a protocol error for damage without attach is a good idea, but I fear it might require a version bump, because of course someone is doing it.
<emersion>
yea
<emersion>
let's just record that idea for now
<pq>
Once a year I think of a "nag" protocol extension. It should be a conduit for compositors to post their complaints to application logs, without crashing the app like protocol errors do.
<ManMower>
if there's no pending buffer, damage without attach should technically unmap the surface and reset any xdg-shell state, just like attaching a null buffer, shouldn't it? ;)
<daniels>
looks like it just needs some tiny reworks if you have half an hour - since we've turned leak checking on in CI, this does occasionally break innocent MRs
<leandrohrb5>
sure, I'll take a look
<leandrohrb5>
for some reason that I don't remember I was not being able to test output hot-plugging (even without this series)
<jadahl>
pq: a "shame" protocol maybe, where compositors do http post requests whining about situations where it wanted to error out clients to some public website
PhilAlbano has quit [Ping timeout: 480 seconds]
<daniels>
leandrohrb5: ahh, thanks
<daniels>
another fun spec question: what's the expected interaction between wl_subsurface.set_position(child, x1, y1), and wl_surface.commit(x2, y2) on the child?
<daniels>
for example, if you do wl_subsurface.set_position(child, 1, 1); wl_surface.commit(); wl_surface@child.offset(20, 20); wl_surface.commit(); wl_subsurface.set_position(child, 3, 3);
<kennylevinsen>
I assume you mean wl_surface.offset(x2, y2)?
<daniels>
yeah
<kennylevinsen>
hmm, offset only really made sense in the scope of a toplevel
<daniels>
in Weston atm, the child's relative pos (assuming no positions) will be (1,1) at the first commit, (21,21) at the second commit, and (3,3) at the second commit
<daniels>
*at the third commit
<kennylevinsen>
for some broken definition of "sense"
<daniels>
yeah, I'd be happy with a conclusion of 'don't offset subsurfs'
<daniels>
just wondering what others do - do you apply the offset but then stomp it with the next set_pos like we do? retain the offset separately from the set_pos? ignore offset?
<emersion>
i think we ignore it in wlr, but not sure
<emersion>
vyivel might know more
<daniels>
jadahl: ?
<kennylevinsen>
I touched that a loooong time ago in sway, too long to remember
<kennylevinsen>
but I have a tingling feeling that sway also explicitly ignored it as it did foo things
<emersion>
the offset is a delta, i don't think it ever makes sense to replace the position with the offset for any role
<jadahl>
daniels: good question, i have no recollection of how subsurfaces consumes the dx/dy
<daniels>
emersion: right, the offset accumulates into the position - but then the next position is a reset which removes any accumulated offset
<emersion>
right
<emersion>
mind, the position is part of the parent state
<emersion>
so i'd be wary of updating the position as part of a child commit
<daniels>
'Sub-surfaces also have another kind of state, which is managed by wl_subsurface requests, as opposed to wl_surface requests. This state includes the sub-surface position relative to the parent surface (wl_subsurface.set_position), [...]'
<daniels>
so that would imply that we should probably just ignore it?
<jadahl>
looks like it ignores dx/dy for subsurfaces, at least since the transaction infrastructure was introduced
<vyivel>
emersion: wlroots ignores the surface offset for subsurfaces yeah
<emersion>
ty
<daniels>
cool, I'd be inclined to introduce an error for trying
<emersion>
yeah…
<jadahl>
errors make me nervous
<MrCooper>
one issue with ignoring the offset for sub-surfaces is that there's no way to atomically change the size and position of unsynchronized sub-surfaces, since sub-surface position changes are always applied only when the parent is committed
<emersion>
or at least document _something_ in the spec
<daniels>
MrCooper: that's literally why the synchronised mode exists tho
<emersion>
daniels: he means size of the sub-surface
<daniels>
jadahl: better than it displaying wrong?
<MrCooper>
it's for consistency with the parent, not self-consistency?
<jadahl>
daniels: my concerns with introducing new errors is that buggy clients that glitched ever so slightly now will crash
<emersion>
basically, resize a sub-surface from the top-left corner, without having the parent involved
<daniels>
yeah, it's the last 5 words that I object to :P
<jadahl>
there are a couple of places with "this will crash [some toolkit] if we're strict, so lets not" because of it
<daniels>
the point of sync mode is that you flip it into sync mode, wait for the child to come with a newly-sized buffer, then commit on the parent with set_position as well
<emersion>
daniels, the use-case would be to resize in desync mode
<emersion>
yeah, in sync mode, it doesn't make sense
<MrCooper>
daniels: the parent is irrelevant for what I described, it's about the position & size of the sub-surface always being consistent with each other
<daniels>
MrCooper: I understand, I'm just saying that trying to do parent-unaware resize + reposition is never really going to work
<MrCooper>
"every frame is perfect" and all that
<jadahl>
every frame is only perfect if you use subsurfaces in sync mode
<daniels>
and in fact in mutter trying that with a top-left resize is just going to result in your window acting as if it were being resized from the bottom right
<emersion>
i think we should document that it's ignored given all current impls, and decide whether MrCooper's use-case is enough to warrant version bump + new behavior
<emersion>
if not, version bump + new error
<daniels>
what would the new behaviour be?
<emersion>
allow offset in desync mode
<emersion>
i don't even know if there are users of desync mode
<daniels>
GSt uses desync in the way it was intended
<daniels>
specifically, that you start in synchronised mode until you've got everything set up, commit and flip into desync for the duration you're running in steady state, then when you need to resize flip briefly back to sync mode
<daniels>
that's why you can change it dynamically with requests, as opposed to the mode being immutable
kts has joined #wayland
<emersion>
there are niche use-cases where i think offset+desync can be used while being frame-perfect
<jadahl>
emersion: gtk3 popups goes desync
<emersion>
for instance, let's say my sub-surface is a spinner which moves back and forth between two points
cmichael has quit [Quit: Leaving]
<jadahl>
or popovers, rather
<jadahl>
(they don't use offsets though, iirc)
cmichael has joined #wayland
<daniels>
emersion: sure - how much code do you want to write to make that possible though? :)
<emersion>
yeah, then there's the question of whether we care about the niche use-case or not
kts has quit [Remote host closed the connection]
kts has joined #wayland
<MrCooper>
I'd be surprised if took a lot of code to make that work in mutter, I just missed this in !1880
kts has quit [Remote host closed the connection]
<daniels>
MrCooper: it's not much code at all for us, just a matter of making sure it actually continues to usefully work, and also how much more complicated we really want our subsurface code to be :P
<daniels>
(bearing in mind that offset co-ords are in subsurf co-ord space whereas set_pos is in parent co-ord space ...)
<MrCooper>
you mean if they use different scaling?
<emersion>
it's a delta, so doesn't matter in what space
kts has joined #wayland
<daniels>
yeah you're right, scale/xform only apply to buffer->surface, so the offset would still move in logical pixels anyway
ahartmetz has quit [Quit: Konversation terminated!]
tzimmermann has quit [Quit: Leaving]
kts has quit [Remote host closed the connection]
kts has joined #wayland
navi has joined #wayland
kts has quit [Remote host closed the connection]
kts has joined #wayland
ivyl has quit [Quit: end of flowers]
ivyl has joined #wayland
alatiera has joined #wayland
iomari892 has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
kts has quit [Remote host closed the connection]
kts has joined #wayland
cmichael has quit [Quit: Leaving]
kts has quit [Remote host closed the connection]
kts has joined #wayland
KALT has joined #wayland
<KALT>
Hi, is transparency broken?
<kennylevinsen>
KALT: no, transparency is not broken. If you are asking about a specific application, wayland server or desktop environment that you see being broken, you should ask in their respective forums
<KALT>
Odd, I'm having difficulty setting up transparency using Vulkan & Wayland. My test application works fine under X11. Under Wayland I've tested various conditions Gnome/KDE/Winit/GLFW/Nvidia(dedicated)/AMD(integrated) with the same result.
<kennylevinsen>
what does your test application do?
<KALT>
Render 3 white squares, on the top left corner, overlapping.
<KALT>
With a transparent swapchain.
<kennylevinsen>
what about the rest of the window?
<KALT>
Nothing, but, I also tried using vkCmdClearColorImage to clear the swapchain to no avail.
<KALT>
There is some interesting behavior, when using GLFW passing a smaller resolution with a higher resolution swapchain causes expected transparency for the part outside of the GLFW resolution.
<KALT>
I noticed that "wl_surface@7.frame(new id wl_callback@18)" is missing in my log. What does wl_surface@frame do?
<kennylevinsen>
it asks the server for a notification next time the server thinks that this surface (window) should start to draw again
<kennylevinsen>
btw, it's always best to share full logs instead of snippets when getting help
<kennylevinsen>
for example, I can see that your program invalidates a region that is 1024x1024, but without the rest I have no idea if that is the whole buffer, and if not, if the rest ever got invalidated correctly
<KALT>
Then again, this is probably not a Wayland issue as there is a working Vulkan demo with transparency.
<KALT>
Gnome & KDE*
<KALT>
On Wayland.
<kennylevinsen>
wayland logs seem good, 1024x1024 surface with 3 GPU buffers and full damage on each commit. I wonder if this could be a gpu quirk if the rest of the buffer hasn't been rendered properly, not super familiar with Vulkan.
<KALT>
Then it's most likely, me having inproperly set-up Vulkan, thanks for your help.
<bl4ckb0ne>
seems like alpha composing issue
<kennylevinsen>
KALT: oh!
<KALT>
?
<kennylevinsen>
You have an opaque region that covers the entire surface
<KALT>
That's in the logs?
<kennylevinsen>
yeah, an opaque region with MAX_INT32 dimensions
<kennylevinsen>
that tells the Wayland server that you will not have any transparency whatsoever so that it can jump corners on compositing
<kennylevinsen>
which, well, glitches things out if you then actually need it
<KALT>
Awesome, thanks kennylevinsen. This also explains the behavior or mismatching window & swapchain resolutions.
<kennylevinsen>
MAX_INT32 is perfectly valid as dimensions on the wire, it just gets capped to the actual surface size
<kennylevinsen>
but something makes your Vulkan WSI set that opaque region up which you don't want
<kennylevinsen>
this bit for reference: > wl_region@32.add(0, 0, 2147483647, 2147483647) \n -> wl_surface@26.set_opaque_region(wl_region@32) \n
<KALT>
Yes! I guess it's window handling library bug.