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
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #wayland
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
Consolatis_ has joined #wayland
Consolatis is now known as Guest1076
Consolatis_ is now known as Consolatis
zebrag has quit [Quit: Konversation terminated!]
Guest1076 has quit [Ping timeout: 480 seconds]
cvmn has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
Seirdy has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
eroux has quit [Read error: Connection reset by peer]
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #wayland
eroux has joined #wayland
canny-v5[m] has joined #wayland
bigigloo has joined #wayland
bigigloo has quit []
canny-v5[m] has left #wayland [#wayland]
repetitivestrain has quit [Read error: Connection reset by peer]
Seirdy has quit [Ping timeout: 480 seconds]
nerdopolis_ has joined #wayland
Seirdy has joined #wayland
cool110 has quit [Remote host closed the connection]
Hypfer has quit [Quit: Ping timeout (120 seconds)]
Hypfer has joined #wayland
cool110 has joined #wayland
nerdopolis_ has quit [Ping timeout: 480 seconds]
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
eroc19909 is now known as eroc1990
rtjure has joined #wayland
dcz_ has joined #wayland
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
jgrulich has joined #wayland
mbalmer has joined #wayland
rtjure has quit [Ping timeout: 480 seconds]
<MrCooper>
emersion: the long term goal is to drop the special handling in Mesa's WSI; first the major Wayland compositors need to do proper mailbox semantics, then Xwayland needs to pass through present requests more directly, then Mesa's WSI can stop treating Xwayland specially
<emersion>
well, because you say that compositors need to be fixed first
<MrCooper>
before the corresponding Xwayland / Mesa changes can land, yes
<emersion>
i disagree
<MrCooper>
one could already work on them though
<MrCooper>
yet nobody does
<emersion>
there have been some attempts
<MrCooper>
I find it ironic that you keep complaining to the one person who's actually spent a lot of effort toward cleaning up this mess
hardening has joined #wayland
rtjure has quit [Ping timeout: 480 seconds]
mvlad has joined #wayland
<wlb>
weston Issue #653 opened by bot crack (unintialized) If no programs are displayed on the desktop ,"weston-touch-calibrator" can never be displayed when set to "panel-position=none" https://gitlab.freedesktop.org/wayland/weston/-/issues/653
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 has quit [Remote host closed the connection]
jgrulich has quit [Remote host closed the connection]
jgrulich has joined #wayland
rasterman has joined #wayland
devilhorns has joined #wayland
cvmn has quit []
rtjure has quit [Read error: No route to host]
rtjure has joined #wayland
Cwiiis_ has left #wayland [#wayland]
rtjure has quit [Ping timeout: 480 seconds]
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #wayland
fahien has quit [Ping timeout: 480 seconds]
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #wayland
devilhorns has quit []
rgallaispou has joined #wayland
devilhorns has joined #wayland
fahien has joined #wayland
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #wayland
txtsd_ has left #wayland [#wayland]
txtsd has joined #wayland
AndroUser2 has quit [Remote host closed the connection]
<pq>
ifreund, if a client is already dying or dead anyway, then why should libwayland-server bother to deliver the remaining requests. It's not going to show on screen, and the compositor cannot reply. That's the rationale, I believe.
<emersion>
pq, this case is to fix a lock screen sending a "screen is unlocked" request
<kennylevinsen>
To be fair this was also not previously an issue with other protocols
<emersion>
right before exiting
<ifreund>
pq: sure, it's fair to say that it doesn't matter for most protocols, but there are edge cases where it does matter and it's currently a huge footgun
<dottedmag>
global state strikes back
<emersion>
global state doesn't really have anything to do with this
<dottedmag>
"screen is locked/unlocked" state lives even though the connection is closed. sounds like a global state
<kennylevinsen>
Can't have the screen automatically unlock when the screen locker crashes :)
<kennylevinsen>
Nothing wrong with well-defined persistent state though. E.g., output configuration
jmdaemon has quit [Ping timeout: 480 seconds]
<MrCooper>
kennylevinsen: that would be bug compatibility with X screen lockers :)
fahien has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
<pq>
ifreund, if you know it matters, have the client do a roundtrip before it disconnects.
<ifreund>
pq: that's the workaround I've put in place for now. I don't find it to be a satisfactory solution though
<pq>
That's the quick thing you can do. I guess it would be possible to patch libwayland-server to deliver requests after HUP but take care to not deliver if any protocol error was raised.
<ifreund>
If the client sends a message to the server it should be able to assume the server recieves it
<pq>
That's not how I understand async protocols to work.
<emersion>
ifreund: hm, what happens with half-closed sockets though?
<emersion>
does libwayland shutdown both sides?
<emersion>
ifreund: the extreme case is the compositor crashing after the client sent the request, in that case, the client can't guarantee the other side will get the message
<pq>
With an async protocol, if you send something, you need to get an ack before the connection closes. Otherwise the connection might have closed after you sent but before the server read it.
<emersion>
the only way to "really" know is a roundtrip
<emersion>
another case would be if the compositor sends a protocol error in parallel with the client's request
<ifreund>
pq: if that's the case I think it needs to be documented better, gotta hop into a meeting now though, back in an hour or so
<pq>
ifreund, in what case would you actually have such guarantees with sockets?
<pq>
I think none.
<emersion>
pq, unix sockets at least ensure that the packets don't get lost in-between
<pq>
sure, but the receiver disappearing is another matter.
<emersion>
so, it's "more reliable" than TCP in a sense
<pq>
you may be thinking of UDP there, TCP is reliable unlike UDP
<emersion>
no, i mean TCP connections can be broken by bad connectivity but Unix sockets can't
<emersion>
also, a compositor going away is pretty rare
<emersion>
but yeah
<emersion>
i agree with you i think
<pq>
right, but that's what's happenining here, right? The connection breaks.
<emersion>
the client ends the connection
<emersion>
after flushing messages
<pq>
yes, but it's no different from client exit vs. client crash.
<pq>
from server perspective
<pq>
in fact, maybe TCP is more reliable than unix socket, because TCP has explicit acks?
<emersion>
TCP's acks are only used at the kernel level
<pq>
or maybe TCP acks only ensure that the... yes
<emersion>
for retransmission
<emersion>
the user never gets to see them
<pq>
not see, no
<pq>
but the kernel knows if the payload has been delivered to userspace or not, so I guess that's not taken into account indeed.
<pq>
anyway we do agree, having the data queued in the kernel is no guarantee that it was delivered
<pq>
still worth documenting since it does not seem to be obvious, but where should it be documented?
<pq>
it affects the client design, so in libwayland-client?
fahien has joined #wayland
<emersion>
maybe wl_display_disconnect, but that's not the perfect place…
<emersion>
btw, pq, welcome back!
bittin has quit [Remote host closed the connection]
<emersion>
hope you enjoyed your time off
<pq>
Thanks! I did, as you can observe of how many times I was here during the past weeks. :-)
<emersion>
ahah, now i feel bad for daniels, who hasn't managed to do the same
bittin has joined #wayland
jgrulich has quit [Ping timeout: 480 seconds]
zebrag has joined #wayland
<ifreund>
pq, emersion: I still don't understand why it wouldn't be better to merge my patch and read all data the client sends on the server side
<ifreund>
what's the advantage to the current approach?
<ifreund>
I find the behavior with the proposed change more predictable in all situations I can think of
<emersion>
ifreund: a client still wouldn't be able to flush() and disconnect() to guarantee that the compositor has received the message
<emersion>
ie, there would still be cases where the compositor doesn't receive the message
<ifreund>
because the compositor may have crashed? isn't it irrelevant then?
<emersion>
because the compositor sends a protocol error for instance
<ifreund>
hmm, yeah ok I see the problem there.
<emersion>
on top of that, this would allow clients to close their write-end without closing their read-end
<emersion>
which would be a pretty broken state
<emersion>
i guess it most likely would result in the socket being closed by the compositor at some point
<ifreund>
a client closing the write end of their socket would result in the compositor calling wl_client_destroy() after it finishes reading all data the client has written with my patch
<ifreund>
I don't think that's problematic
ybogdano has joined #wayland
<ifreund>
the race with abnormal server-side client termination due to a protocol error is a convincing reason why the roundtrip is needed even with my patch
<emersion>
i mean, if the compositor reads a message, then needs to send a reply to the client in response, but then figures out it can't because that side is closed, and then disconnects the client without reading the rest of the messages
<emersion>
it wouldn't be great
<ifreund>
hmm, I wonder if we should have built an ack_unlock event into the ext-session-lock protocol to handle this case
<emersion>
this doesn't sound very different from a regular roundtrip
<emersion>
if the client's goal is just to make sure the compositor has seen the unlock request
<emersion>
we could add a warning/note to the protocol, btw
<ifreund>
yeah I was certainly planning on doing so
<ifreund>
perhaps wl_display_flush() would be the proper place to document that sending data to the server does not mean that the server recieves it?
MrCooper has quit [Remote host closed the connection]
markbolhuis has joined #wayland
markbolhuis has quit []
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #wayland
markbolhuis has joined #wayland
ybogdano has joined #wayland
MrCooper has joined #wayland
fahien has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
abeltramo5 has joined #wayland
jmdaemon has joined #wayland
abeltramo has quit [Ping timeout: 480 seconds]
Lightsword_ has left #wayland [#wayland]
Lightsword has joined #wayland
Seirdy has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
ybogdano has joined #wayland
mbalmer has quit []
rasterman has joined #wayland
Seirdy has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
Seirdy has quit []
Seirdy has joined #wayland
markbolhuis1 has joined #wayland
markbolhuis has quit [Ping timeout: 480 seconds]
markbolhuis1 has quit [Ping timeout: 480 seconds]
buh0 has joined #wayland
<zamundaaa[m]>
MrCooper: would removing the need for Mesa to use `PresentOptionAsync` for mailbox resolve the problem with using it for tearing anytime soon though?
markbolhuis has joined #wayland
<zamundaaa[m]>
Even if Xwayland could do mailbox properly right now, there'd still be old versions of Mesa around for ages that will then potentially cause tearing where not actually desired
<zamundaaa[m]>
So with that in mind, would adding new X11 API specifically for Xwayland to allow tearing be an option?
buh0 has quit [Quit: Bye!]
caveman has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
rasterman has quit [Read error: Connection reset by peer]
rv1sr has quit []
dcz_ has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
AndroUser2 has joined #wayland
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #wayland
cyberpear has quit [Quit: Connection closed for inactivity]