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
fmuellner has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
erodrgz has quit [Read error: Connection reset by peer]
erodrgz has joined #wayland
<RAOF>
Hm. It seems like it would be a bad idea for a client to do something weird with shm buffers, like have two buffers overlap the backing store by using stride = width × 2 × bpp and offsetting the second buffer by width × bpp, but it doesn't seem like there's any reason that would be an error.
* RAOF
is just trying to work out exactly what invariants he can usefully assert.
<RAOF>
I guess clients might even almost- sensibly do that for interlaced buffers 🤷♀️
danie1dg has left #wayland [#wayland]
danieldg has joined #wayland
<danieldg>
RAOF: that could be practical for something like a tileset, especially if it's something like minimize/maximize/close buttons where the 'normal' image is beside-each-other
<RAOF>
Mainly what I'm looking for is a reason not to feel bad about not trying to detect overlapping buffer allocations :)
cool110_ has quit [Remote host closed the connection]
cool110 has joined #wayland
Leopold_ has quit [Remote host closed the connection]
sozuba has joined #wayland
slattann has joined #wayland
tzimmermann has joined #wayland
naveenk2 has joined #wayland
hardening has joined #wayland
dcz_ has joined #wayland
rv1sr has joined #wayland
Company has quit [Quit: Leaving]
hardening_ has joined #wayland
hardening has quit [Ping timeout: 480 seconds]
pochu has joined #wayland
slattann has quit [Read error: Connection reset by peer]
danvet has joined #wayland
<RAOF>
Coarse grained.
<RAOF>
The opaque region is purely an optimisation hint, and it rather defeats the purpose if that's very fine grained.
<RAOF>
(If the compositor wanted fine-grained opacity it can just read the alpha value out of the buffer!)
<RAOF>
The goal is things like “this surface is entirely behind the opaque region of this other surface, so there's no need to draw it at all".
<emersion>
talking to someone?
<i509VCB>
yshui: you probably need to identify with NickServ. Bridge disconnected for a bit today
jgrulich has joined #wayland
mvlad has joined #wayland
m5zs7k has quit [Ping timeout: 480 seconds]
m5zs7k has joined #wayland
cool110 has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
cool110 has joined #wayland
manuel1985 has joined #wayland
<yshui`>
emersion, sorry, it was me 😅 matrix reconnected and did not authenticate for me. the question was if it makes sense for opaque regions to be bitmaps
Dami_Lu has quit [Read error: Connection reset by peer]
<yshui`>
RAOF (he/they): thanks, that makes sense.
Dami_Lu has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #wayland
fahien has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
chipxxx has quit [Read error: Connection reset by peer]
<pq>
RAOF, overlapping buffer allocations are not forbidden. Those interlaced buffers like you describe, I would expect them to just work, since the wl_shm_pool interface allows it.
<pq>
RAOF, the worst that can happen is the client shooting its own foot.
<pq>
at least, I don't *recall* them being forbidden in the protocol spec
<RAOF>
Yeah. I just like to notify clients promptly when they shoot their feet if at all possible 😀
<dottedmag>
pq: I recently read this part of spec, it is not specifically forbidden.
<dottedmag>
RAOF: By... protocol error?
<RAOF>
When available, yes!
<RAOF>
“doing this reliably and instantly crashes the app” is much friendlier to developers than “sometimes rendering is weird 🤷♀️”
<pq>
mostly I agree with that, but one also needs to think whether it could have actually worked and be used intentionally
Guest1644 has quit []
devilhorns has joined #wayland
chipxxx has joined #wayland
chipxxx has quit []
chipxxx has joined #wayland
fahien has quit [Ping timeout: 480 seconds]
<dottedmag>
RAOF: "doing this reliably and instantly crashes the app under one minor compositor" is probably not a good enough.
<dottedmag>
s/a good/good/
<dottedmag>
Especially when the protocol says something is allowed, though might be stupid to do.
dos1 has quit [Quit: Kabum!]
dos1 has joined #wayland
<RAOF>
Oh, yeah. It's only sensible to protocol error when it's actually an error.
<RAOF>
Otherwise it's just a sparkling compositor bug!
<RAOF>
(or, I guess, a protocol bug that it's not forbidden)
sozuba_tmp has joined #wayland
sozuba has quit [Ping timeout: 480 seconds]
robert_mader has joined #wayland
glennk has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
Levans has quit [Write error: connection closed]
q234rty[m][m] has quit [Write error: connection closed]
BilalElmoussaoui[m] has quit [Write error: connection closed]
unrelentingtech has quit [Write error: connection closed]
i509VCB has quit [Write error: connection closed]
varlad[m] has quit [Write error: connection closed]
smasher_tati[m] has quit [Write error: connection closed]
Ryhon[m] has quit [Write error: connection closed]
danburd[m] has quit [Write error: connection closed]
ehfd[m] has quit [Write error: connection closed]
inkbottle[m] has quit [Write error: connection closed]
bdaase[m] has quit [Write error: connection closed]
doras has quit [Write error: connection closed]
deknos82[m] has quit [Write error: connection closed]
DemiMarieObenour[m] has quit [Write error: connection closed]
jasyuiop[m] has quit [Write error: connection closed]
rubo_[m] has quit [Write error: connection closed]
GrahamPerrin[m] has quit [Write error: connection closed]
davidre has quit [Write error: connection closed]
japchae[m] has quit [Write error: connection closed]
windowsxp[m] has quit [Write error: connection closed]
ttancos[m] has quit [Write error: connection closed]
Sumera[m] has quit [Write error: connection closed]
ujineli[m] has quit [Write error: connection closed]
MatrixTravelerbot[m]1 has quit [Write error: connection closed]
underpantsgnome[m] has quit [Write error: connection closed]
flyingketh[m] has quit [Write error: connection closed]
Guest1631 has quit [Write error: connection closed]
ki[m] has quit [Write error: connection closed]
unix-supremacist[m] has quit [Write error: connection closed]
vchernin[m] has quit [Write error: connection closed]
teh1[m] has quit [Write error: connection closed]
junglerobba[m] has quit [Write error: connection closed]
apol[m] has quit [Write error: connection closed]
Guest1653 has quit [Write error: connection closed]
ozwald1[m] has quit [Write error: connection closed]
robertmader[m] has quit [Write error: connection closed]
GeorgesStavracasfeaneron[m] has quit [Write error: connection closed]
hasebastian[m] has quit [Write error: connection closed]
nielsdg has quit [Write error: connection closed]
Nico has quit [Write error: connection closed]
Shimmy[m] has quit [Write error: connection closed]
ammen99[m] has quit [Write error: connection closed]
Florian[m]1 has quit [Write error: connection closed]
cousinofthor[m] has quit [Write error: connection closed]
drakulix[m] has quit [Write error: connection closed]
botiapa[m] has quit [Write error: connection closed]
Guest1662 has quit [Write error: connection closed]
zamundaaa[m] has quit [Write error: connection closed]
tleydxdy has quit [Write error: connection closed]
ahmadraniri[m] has quit [Write error: connection closed]
hch12907 has quit [Write error: connection closed]
arichardson[m] has quit [Write error: connection closed]
pitsch[m] has quit [Write error: connection closed]
rails[m] has quit [Write error: connection closed]
xerpi[m] has quit [Write error: connection closed]
FellFromTheSky[m] has quit [Write error: connection closed]
diamondburned[m] has quit [Write error: connection closed]
nazarewk[m] has quit [Write error: connection closed]
ongy[m] has quit [Write error: connection closed]
niecoinny[m] has quit [Write error: connection closed]
yshui` has quit [Write error: connection closed]
RAOF has quit [Write error: connection closed]
gnustomp[m] has quit [Write error: connection closed]
unix has quit [Write error: connection closed]
RomanGilg[m] has quit [Write error: connection closed]
hex[m]1 has quit [Write error: connection closed]
j-james[m] has quit [Write error: connection closed]
q234rty[envs][m] has quit [Write error: connection closed]
Kelseyjgilbert[m] has quit [Write error: connection closed]
FbioPacheco[m] has quit [Write error: connection closed]
[old]freshgumbubbles[m] has quit [Write error: connection closed]
MarcusBritanicus[m] has quit [Write error: connection closed]
pac85[m] has quit [Write error: connection closed]
halfline[m] has quit [Write error: connection closed]
jryans has quit [Write error: connection closed]
frytaped[m] has quit [Write error: connection closed]
psydroid[m] has quit [Write error: connection closed]
bluepenquin has quit [Write error: connection closed]
heftig has quit [Write error: connection closed]
toggleton[m] has quit [Write error: connection closed]
YaLTeR[m] has quit [Write error: connection closed]
edrex[m] has quit [Write error: connection closed]
anomalous_creator[m] has quit [Write error: connection closed]
Guest1623 has quit [Write error: connection closed]
cb5r[m] has quit [Write error: connection closed]
cmeissl[m] has quit [Write error: connection closed]
emilio[m] has quit [Write error: connection closed]
JosExpsito[m] has quit [Write error: connection closed]
Mershl[m] has quit [Write error: connection closed]
scriptingdad[m] has quit [Write error: connection closed]
zaibon[m] has quit [Write error: connection closed]
jmariondev[m] has quit [Write error: connection closed]
Poly[m] has quit [Write error: connection closed]
AndrewAylett[m] has quit [Write error: connection closed]
d_ed[m] has quit [Write error: connection closed]
chipxxx has quit [Read error: No route to host]
ahmadraniri[m] has joined #wayland
devilhorns has quit []
nerdopolis_ has joined #wayland
chipxxx has joined #wayland
eroux has quit [Remote host closed the connection]
eroux has joined #wayland
eroux has quit [Remote host closed the connection]
<paulk>
pq: daniels: ^^^ there's my attempt at fixing the screenshooter issue described yesterday -- hope I got it right :)
Moprius has joined #wayland
zebrag has joined #wayland
Moprius has quit [Quit: bye]
rasterman has joined #wayland
chipxxx has quit [Read error: Connection reset by peer]
chipxxx has joined #wayland
Company has joined #wayland
markbolhuis has joined #wayland
<markbolhuis>
Hi all. wl_global_create does not recycle name ids. However that is stated nowhere in the wayland spec. I'd like to use this behavior in my programs but I don't want rely on implementation. Would explicitly stating this in the spec be ok?
<emersion>
how do you want to "use" that behavior?
<emersion>
also, the IDs may be recycled eventually
<emersion>
e.g. when the counter wraps around
<markbolhuis>
I'd like to rely on the fact that the ids are unique even if the global is removed
<markbolhuis>
Doesn't wrapping around cause problems anyway? Since it wraps to id 0 which is reserved?
<kennylevinsen>
capping the number of unique globals that can have existed during the entire lifetime of a client (rather than just max concurrent globals) by disallowing ID reuse would be a new restriction
<markbolhuis>
Is that an issue given that it's a uint32_t?
<kennylevinsen>
Skipping 0 on wrap around is not an issue, if we don't already.
<dottedmag>
markbolhuis: would you like to rely on this fact in a client or in a server?
fahien has joined #wayland
<markbolhuis>
I'd like, as client, to know that the server will never send a name id that it's already sent. It's not a huge problem if it doesn't. I'll just have to use my own identifier.
sozuba_tmp has quit [Ping timeout: 480 seconds]
<kennylevinsen>
My stance would be that it is an erroneous assumption to make, and the proper thing is just to handle globals oer the current spec properly (I.e. no persistent uniqueness guarantee)
<dottedmag>
I'm afraid it's not guaranteed. Actually I have an in-progress compositor that will reuse global numbers, and in addition these global numbers won't be contiguous
<kennylevinsen>
Object IDs are aggressively reused - globals behaving differently is likely just because it doesn't generate enough IDs to need such code yet, but if it should change I'd say the proper one is to add the same aggressive reuse for globals.
<emersion>
dottedmag: be careful about race conditions
<kennylevinsen>
Wouldn't hurt to have a compositor shake out such races :P
<emersion>
we kind of rely on non-aggressive global name re-use to spot races right now, because clients have no way to ack a global_remove event
<emersion>
in principle i'm a fan of uint64_t never-reused IDs
<kennylevinsen>
hmm not sure I am, but it's also unlikely to ever be an issue
<kennylevinsen>
would certainly require many output hotplugs to burn through
<markbolhuis>
Ok, thanks. Would it be ok if the spec gets updated to explicitly state that names ids might be reused after a global_remove event?
<emersion>
yeah, i don't know of a situation where we'd use a huge number of globals
<dottedmag>
emersion: thanks, I haven't thought about it!
sozuba_tmp has joined #wayland
yshui` has joined #wayland
<yshui`>
in theory, if a global is removed and then have its id reused, while a client bind with that id is in-flight, the client would bind an unexpected global.
<yshui`>
is that the kind of race we were talking about?
<emersion>
yes
<yshui`>
can we make this behavior somewhat required? e.g. "id won't be reused in a reasonable time frame, to avoid races"?
<emersion>
not great to have in a spec
<vyivel>
yshui`: global_remove doesn't destroy the global on the server side, it just remains inert until the client destroys it explicitly
<vyivel>
at least the spec says so
<emersion>
vyivel: we're talking purely about global names here, not objects
<vyivel>
well, if an object is alive, its id can't be reused
<emersion>
the global name is separate from the object IDs
<yshui`>
emersion, hmm, why? is it because we don't want to impose too much implementation details?
<emersion>
yshui`: it's pretty vague
<vyivel>
oh yeah nvm
<yshui`>
ah,ok. then what about "id must keep going up until it wraps around"?
jgrulich has quit [Ping timeout: 480 seconds]
cool110_ has joined #wayland
cool110 has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
DemiMarie 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
bdaase[m] has joined #wayland
BilalElmoussaoui[m] has joined #wayland
bluepenquin has joined #wayland
botiapa[m] has joined #wayland
cb5r[m] has joined #wayland
RAOF has joined #wayland
cmeissl[m] has joined #wayland
cousinofthor[m] has joined #wayland
d_ed[m] has joined #wayland
danburd[m] has joined #wayland
davidre has joined #wayland
Nico has joined #wayland
deknos82[m] has joined #wayland
DemiMarieObenour[m] has joined #wayland
diamondburned[m] has joined #wayland
Guest1738 has joined #wayland
doras has joined #wayland
drakulix[m] has joined #wayland
edrex[m] has joined #wayland
ehfd[m] has joined #wayland
emilio[m] has joined #wayland
FbioPacheco[m] has joined #wayland
GeorgesStavracasfeaneron[m] has joined #wayland
FellFromTheSky[m] has joined #wayland
flyingketh[m] has joined #wayland
[old]freshgumbubbles[m] has joined #wayland
frytaped[m] has joined #wayland
gnustomp[m] has joined #wayland
Guest1750 has joined #wayland
GrahamPerrin[m] has joined #wayland
halfline[m] has joined #wayland
hasebastian[m] has joined #wayland
hch12907 has joined #wayland
Florian[m]1 has joined #wayland
heftig has joined #wayland
Guest1765 has joined #wayland
hex[m]1 has joined #wayland
i509VCB has joined #wayland
inkbottle[m] has joined #wayland
j-james[m] has joined #wayland
japchae[m] has joined #wayland
jasyuiop[m] has joined #wayland
Kelseyjgilbert[m] has joined #wayland
jmariondev[m] has joined #wayland
junglerobba[m] has joined #wayland
JosExpsito[m] has joined #wayland
jryans has joined #wayland
Levans has joined #wayland
MarcusBritanicus[m] has joined #wayland
Mershl[m] has joined #wayland
nazarewk[m] has joined #wayland
niecoinny[m] has joined #wayland
nielsdg has joined #wayland
ongy[m] has joined #wayland
teh1[m] has joined #wayland
ozwald1[m] has joined #wayland
pac85[m] has joined #wayland
pitsch[m] has joined #wayland
Poly[m] has joined #wayland
psydroid[m] has joined #wayland
q234rty[envs][m] has joined #wayland
q234rty[m][m] has joined #wayland
rails[m] has joined #wayland
robertmader[m] has joined #wayland
RomanGilg[m] has joined #wayland
rubo_[m] has joined #wayland
Ryhon[m] has joined #wayland
DemiMarie is now known as Guest1773
scriptingdad[m] has joined #wayland
smasher_tati[m] has joined #wayland
Sumera[m] has joined #wayland
Shimmy[m] has joined #wayland
underpantsgnome[m] has joined #wayland
tleydxdy has joined #wayland
toggleton[m] has joined #wayland
ttancos[m] has joined #wayland
ki[m] has joined #wayland
ujineli[m] has joined #wayland
unix has joined #wayland
unix-supremacist[m] has joined #wayland
unrelentingtech 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
zaibon[m] has joined #wayland
zamundaaa[m] has joined #wayland
tzimmermann has quit [Quit: Leaving]
<dottedmag>
yshui`: There is no requirement for IDs to be contiguous.
<dottedmag>
I actually intend to use it to encode type of global into ID (so that real globals are 1..N, inputs are 0xsomething... and outputs are 0xsomethingmore...)
<emersion>
"real globals"
<dottedmag>
static ones
<emersion>
(i understand, just a funny name)
fahien has quit [Remote host closed the connection]
fahien has joined #wayland
<yshui`>
dottedmag, I didn’t say they have to be contiguous 😉
<yshui`>
But I think at least object IDs are actually required to be contiguous
<yshui`>
> For efficiency purposes, the IDs are densely packed in the sense that the ID N will not be used until N-1 has been used. Any ID allocation algorithm that does not maintain this property is incompatible with the implementation in libwayland.
<dottedmag>
yep, object IDs are different, and actually unfortunate, matter.
<dottedmag>
here compositor has to behave in a way that won't blow up libwayland-client :(
caveman has quit [Remote host closed the connection]