ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Moprius has quit [Quit: bye]
<riteo>
well, I'll go. I'll check the logs the next day if someone wants to answer me
<riteo>
bye!
riteo has quit [Quit: epic global moment]
ahartmetz has quit [Quit: Konversation terminated!]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
ciara has joined #wayland
nnm has quit []
Brainium has quit [Quit: Konversation terminated!]
nnm has joined #wayland
tent405 has joined #wayland
___nick___ has joined #wayland
cool110 has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit [Ping timeout: 480 seconds]
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
tzimmermann has joined #wayland
sima has joined #wayland
pH5_ is now known as pH5
cool110 has quit [Quit: ZNC 1.8.2+deb3build2 - https://znc.in]
akallabeth[m] has quit [Quit: Bridge terminating on SIGTERM]
diamondburned[m] has quit [Quit: Bridge terminating on SIGTERM]
robertmader[m] has quit [Quit: Bridge terminating on SIGTERM]
Saijin_Naib has quit [Quit: Bridge terminating on SIGTERM]
sythemeta847[m] has quit []
general_j[m] has quit []
swick[m] has quit [Quit: Bridge terminating on SIGTERM]
davidre has quit [Quit: Bridge terminating on SIGTERM]
orowith2os has quit []
Naruto[m] has quit [Quit: Bridge terminating on SIGTERM]
Paul[m] has quit [Quit: Bridge terminating on SIGTERM]
KingoftheElves[m] has quit [Quit: Bridge terminating on SIGTERM]
GrahamPerrin[m] has quit [Quit: Bridge terminating on SIGTERM]
RAOF has quit [Quit: Bridge terminating on SIGTERM]
j-james[m] has quit [Quit: Bridge terminating on SIGTERM]
ttancos[m] has quit [Quit: Bridge terminating on SIGTERM]
Coelacanthus[m] has quit [Quit: Bridge terminating on SIGTERM]
qaqland[m] has quit [Quit: Bridge terminating on SIGTERM]
NepNepdmsalwaysopen[m] has quit [Quit: Bridge terminating on SIGTERM]
hariselldon[m] has quit [Quit: Bridge terminating on SIGTERM]
ammen99[m] has quit [Quit: Bridge terminating on SIGTERM]
ongy[m] has quit [Quit: Bridge terminating on SIGTERM]
vchernin[m] has quit [Quit: Bridge terminating on SIGTERM]
Nova[m] has quit [Quit: Bridge terminating on SIGTERM]
RomanGilg[m] has quit [Quit: Bridge terminating on SIGTERM]
rails[m] has quit [Quit: Bridge terminating on SIGTERM]
ambasta[m] has quit [Quit: Bridge terminating on SIGTERM]
d_ed[m] has quit [Quit: Bridge terminating on SIGTERM]
ahmadraniri[m] has quit [Quit: Bridge terminating on SIGTERM]
danburd[m] has quit [Quit: Bridge terminating on SIGTERM]
niecoinny[m] has quit [Quit: Bridge terminating on SIGTERM]
gnustomp[m] has quit []
pac85[m] has quit [Quit: Bridge terminating on SIGTERM]
sergi has quit [Quit: Bridge terminating on SIGTERM]
DemiMarie has quit [Quit: Bridge terminating on SIGTERM]
joantorres[m] has quit [Quit: Bridge terminating on SIGTERM]
hex[m]1 has quit [Quit: Bridge terminating on SIGTERM]
q234rty[m][m] has quit [Quit: Bridge terminating on SIGTERM]
Kelseyjgilbert[m] has quit [Quit: Bridge terminating on SIGTERM]
Nico has quit []
YaLTeR[m] has quit [Quit: Bridge terminating on SIGTERM]
dani-g5x[m] has quit [Quit: Bridge terminating on SIGTERM]
Sumera[m] has quit []
arichardson[m] has quit [Quit: Bridge terminating on SIGTERM]
yshui` has quit [Quit: Bridge terminating on SIGTERM]
rajveermalviya[m] has quit []
junglerobba[m] has quit [Quit: Bridge terminating on SIGTERM]
Shimmy[m] has quit [Quit: Bridge terminating on SIGTERM]
japchae[m] has quit [Quit: Bridge terminating on SIGTERM]
Ryhon[m] has quit [Quit: Bridge terminating on SIGTERM]
tzx[m] has quit [Quit: Bridge terminating on SIGTERM]
basemale has quit [Quit: Bridge terminating on SIGTERM]
ujineli[m] has quit []
Max1 has quit [Quit: Bridge terminating on SIGTERM]
doras has quit [Quit: Bridge terminating on SIGTERM]
nazarewk[m] has quit []
pobthebuilder[m] has quit [Quit: Bridge terminating on SIGTERM]
Guest2947 has quit [Quit: Bridge terminating on SIGTERM]
fallenchromium[m] has quit [Quit: Bridge terminating on SIGTERM]
zebrag[m] has quit [Quit: Bridge terminating on SIGTERM]
emilio[m]1 has quit [Quit: Bridge terminating on SIGTERM]
Poly[m] has quit [Quit: Bridge terminating on SIGTERM]
sewn has quit []
ghostte[m] has quit [Quit: Bridge terminating on SIGTERM]
JosExpsito[m] has quit [Quit: Bridge terminating on SIGTERM]
heftig has quit [Write error: connection closed]
nielsdg has quit [Write error: connection closed]
jelmer has quit [Write error: connection closed]
unix-supremacist[m] has quit [Write error: connection closed]
teh1[m] has quit [Write error: connection closed]
apol[m] has quit [Write error: connection closed]
bdaase[m] has quit [Write error: connection closed]
Vanfanel has quit [Write error: connection closed]
xerpi[m] has quit [Write error: connection closed]
Mershl[m] has quit [Write error: connection closed]
zamundaaa[m] has quit [Write error: connection closed]
q234rty has quit [Write error: connection closed]
mboudr35[m] has quit [Write error: connection closed]
[old]freshgumbubbles[m] has quit [Write error: connection closed]
elinor has quit [Write error: connection closed]
botiapa[m] has quit [Write error: connection closed]
Bran[m] has quit [Write error: connection closed]
rubo_[m] has quit [Write error: connection closed]
FbioPacheco[m] has quit [Write error: connection closed]
zaibon[m] has quit [Write error: connection closed]
drakulix[m] has quit [Write error: connection closed]
windowsxp[m] has quit [Write error: connection closed]
cousinofthor[m] has quit [Write error: connection closed]
varlad[m] has quit [Write error: connection closed]
AndrewAylett[m] has quit [Write error: connection closed]
deknos82[m] has quit [Quit: Bridge terminating on SIGTERM]
jryans has quit [Quit: Bridge terminating on SIGTERM]
heeen[m] has quit [Quit: Bridge terminating on SIGTERM]
go4godvin has quit [Quit: Bridge terminating on SIGTERM]
crazybyte has quit [Ping timeout: 480 seconds]
<pq>
riteo, depends on the global. wl_compositor would never go away for what clients care. wl_seat and wl_output can and do come and go dynamically. A headless compositor as a RDP/VNC server could very well do that.
<pq>
It would be logical for each RDP/VNC viewer connection to exhibit its own wl_output and wl_seat. If no viewer is connected, no output or seats would exist. If multiple can connect simultaneously, it would be the natural thing to do.
<pq>
That could apply with head-ful compositors too. Then remote input does not get confused with local input, and remote output can repaint on its own pace.
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
crazybyte has joined #wayland
Cyrinux9 has quit []
Cyrinux9 has joined #wayland
tanty has quit [Quit: Ciao!]
<any1>
The transient-seat protocol does this for wl_seat. It's almost past the finishing line. Only needs 1 ack, afaik. :)
<emersion>
any1: if you have time, can you address the typo?
bcheng has quit [Remote host closed the connection]
bcheng has joined #wayland
junaid has joined #wayland
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
cmichael has quit [Quit: Leaving]
kts has joined #wayland
tzimmermann has quit [Quit: Leaving]
kts has quit [Remote host closed the connection]
kts has joined #wayland
O5KV5980_ has joined #wayland
O5KV5980_ is now known as O5KV5980
kts has quit [Remote host closed the connection]
navi has joined #wayland
Brainium has joined #wayland
junaid has quit [Remote host closed the connection]
mvlad has quit [Quit: Leaving]
riteo has joined #wayland
<riteo>
hi! It's me again; I've read the logs and I've just seen that somebody answered me
<emersion>
pekka has
<riteo>
pq: yeah, seats and outputs are definitely hotpluggable by design
<riteo>
but there's no guarantee of what is and what isn't, that's the annoying thing
<riteo>
I've heard multiple times the idea of using globals for a permission system (which would be really nice actually). Right now the spec allows this sort of thing but this pretty much means that almost any global might suddenly disappear as far as the client's concerned
<danieldg>
I'd say that 'suddenly appear' is more likely than disappear
<riteo>
mh yeah
<riteo>
perhaps the spec could guarantee no destruction for most globals?
<riteo>
this would still allow the permission system thing
<danieldg>
I would think that instead of disappearing, the server would choose to reject requests that are no longer allowed
<riteo>
isn't this already current behaviour?
<danieldg>
(and that this should be added to protocols that don't already support it)
<danieldg>
for some protocols, maybe
<riteo>
I'm pretty sure that if a global gets deleted all requests to its proxy will be rejected
<emersion>
i think it's fine if a global is removed, but that removal is not handled by the client
<emersion>
this is a situation that needs to be supported anyways because of races
<danieldg>
right. The server can't rely on that happening anyway, so might as well just make it harmless
<riteo>
yeah I'm pretty sure that the core spec already covers this part
<emersion>
a compositor which wants to update wl_shm formats could remove and re-create the wl_shm global
<emersion>
old clients continue to use the old global, new clients will use the new one
<riteo>
wouldn't this make the old global useless?
<danieldg>
that would mean the server still has to support all the old formats forever (though maybe they're inefficient)
<riteo>
the spec says explicitly: The object remains valid and requests to the object will be ignored until the client destroys it, to avoid races between the global going away and a client sending a request to it.
<danieldg>
but is that ignoring transitive?
<danieldg>
(for shm: would it apply to attaching buffers)
<riteo>
that's actually a good question
<riteo>
I assume no for the most part
<danieldg>
and does it invalidate existing buffers that haven't changed recently (say, cursors or subsurfaces that are static)
<riteo>
because most stuff would require some requests to be done, no?
<riteo>
I'm not really sure about wl_buffers creted by wl_shm but other globals would be probably affected
<danieldg>
this feels like the spec was only concerned with seat/output removals, where the objects don't make sense to use
<riteo>
yeah
<danieldg>
I could see things like dmabuf being unusable upon removal, though
<riteo>
they're pretty much event handlers
<danieldg>
say it's attached to a hot-unpluggable GPU
<riteo>
indeed, most other objects depend on being able to send messages so I presume that they would be unusable
<riteo>
I really feel like there's some implicit distinction between globals that's not clearly defined by the spec
<emersion>
i think there are two kinds indeed
<riteo>
I think we haven't stumbled on this before as much because there weren't as many extension protocols
<emersion>
one kind advertises support for a feature, there can be either 0 or 1 such globals
<emersion>
the other kind reflects the presence of a resource, there can be any number
<riteo>
but now with pointer constraints, relative pointers and tablet support I have to handle a lot of cases as they are pretty much just seat extensions
<riteo>
so I have to iterate in all my seat state struct to clear/populate depending on which global got removed/added
<emersion>
just ignore remove if you're not interested in it
<riteo>
emersion: regarding the distinction I'd also consider practically that the feature globals are very likely to just pop into existence and not be destroyed at all after
ciara has quit []
<emersion>
e.g. no need to handle remove for relative-pointer
<riteo>
although that could break some very very niche cases
<riteo>
emersion: are you sure? If a seat pops up it's gonna ask the now "empty" relative pointer global for a relative pointer
<riteo>
what happens then?
<emersion>
it creates an inert object
<riteo>
oh nice
<emersion>
that's the only non-racy way to implement it
<riteo>
that would probably make the code I'm working on more maintainable
<riteo>
a tiny bit
<riteo>
oh there's also another thing
<riteo>
like, is there some implied order of global creation?
<emersion>
no
<riteo>
wouldn't it make sense to create extension globals before actual globals or would it be too messy?
<emersion>
there's no such guarantee
<riteo>
fair
<emersion>
e.g. i have zwp_pointer_gestures_v1 coming after wl_seat, for instance
<emersion>
on my current machine
<riteo>
the reasoning was that rn I have to populate the seat's state both from the global handling code for the seat and for the extensions
<emersion>
yeah, it's a pain to handle correctly in client code
<emersion>
but that ship has sailed
<emersion>
maybe something to add in the wayland-next thread
<dottedmag>
At least there is an indication "no more globals for now" at startup.
<riteo>
rn on godot I have to handle seat extensions in the seat add/destroy event, in the extensions add/destroy event and in the actual application destructor
<riteo>
wayland-next?
<dottedmag>
riteo: ideas for incompatible Wayland 2
<emersion>
just a list of mistakes basically
<riteo>
oh that's an interesting idea to have "already" at this stage
<emersion>
well, we aren't planning anything, fwiw
<riteo>
do you have a link for said list of mistakes?
<emersion>
just trying to document stuff
<riteo>
yeah it'd be a mess to plan but interesting nonetheless
<danieldg>
some of them might be possible to 'backport' to wayland 1, which would end up being useful