ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
feaneron has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
Calandracas_ has quit []
Calandracas has joined #wayland
abeltramo589523 has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
guru_ has joined #wayland
abeltramo589523 has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
linkmauve has left #wayland [Error from remote client]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
linkmauve has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
kaiser2nd has quit [Quit: Lost terminal]
melonai5 has quit []
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
fmuellner has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
Company has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
Brainium has quit []
guru__ has joined #wayland
melonai5 has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
feaneron has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
mxz__ has joined #wayland
mxz_ has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
mxz__ is now known as mxz
mxz_ has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
caveman has quit [Remote host closed the connection]
bindu_ has quit [Remote host closed the connection]
caveman has joined #wayland
bindu has joined #wayland
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
kts has joined #wayland
privacy has quit [Remote host closed the connection]
Guest1549 has quit [Remote host closed the connection]
<colinmarc>
what's the correct timestamp value for wp-presentation for my remote compositor? it seems like I need to support this protocol for gpu accelerated apps, but I'm not sure what to put in the callback. I have a virtual refresh timer in my compositor, should I just treat that instant as "the pixels turn to light"? or try to estimate the display latency all the way on the client side, including network?
<colinmarc>
my goal is just the best compatibility with existing apps
<kennylevinsen>
The purpose of the presentation timestamp is to communicate, in the local clock, when the image hit your eyeball
<kennylevinsen>
well, at least when the image arrive at the display
<colinmarc>
Right, but this is a remote-desktop situation. even if I were able to add up network + remote client display latency, it's not clear that that would be useful to the wayland client. For the purposes of audio sync, it seems like it would just want to match up when the video frame is encoded to when the audio frame is encoded
<kennylevinsen>
I am not sure how the audio latency would be dealt with in this case. In theory, you'd want the presentation time for both a video frame and audio frame so that the client could sync up the two...
<kennylevinsen>
(Or one could solve the problem the opposite way by attaching the intended time of presentation for both frames and then let the respective servers deal with it)
<kennylevinsen>
In any case, I'd start out with just doing it the way the protocol intended, then if that's terrible use that as a point of discussion :)
<kennylevinsen>
in which case, a requested presentation feedback should emit the timestamp of when the display server presented the content, which would include transfer
<colinmarc>
Right, it seems like the wayland protocol is assuming that the audio latency is measured out of band and the client deals with matching those up. Since I control the pulseaudio side, I could indeed give realistic values for the audio latency as well. it seems more like it would be effective to fudge both up to the network point, though
<kennylevinsen>
That might be good enough for syncing up video, but some apps might want to know the actual system latency - say, a rhythm game
<kennylevinsen>
(ignoring the fact that playing osu! over remote desktop would be cursed)
<colinmarc>
The remote desktop part has its own sync mechanism, because the encoded audio and video frames have a PTS attached
<colinmarc>
including the network latency in the information given to the game just seems like extra complexity to me
<colinmarc>
I guess it could try to include input latency, to your point. but most games like that allow you to configure it anyway
jlco has joined #wayland
<colinmarc>
One thing I'm confused about is how apps use presentation time, in practice. I get the mpv audio/video sync case. But it also seems like the mesa/xwayland/etc pipeline uses it for games, as well?
nerdopolis has joined #wayland
<MrCooper>
FWIW, Xwayland doesn't use wp-presentation yet, it uses frame events only so far
<colinmarc>
ah, that's good to know, thank you!
<colinmarc>
seems like I had a false impression somewhere
<any1>
presentation time is not only used for audio/video sync but also for pacing during playback. If you have a jittery network, your frames will not arrive at a steady rate, so a jitter buffer is needed for smooth playback.
YaLTeR[m] has joined #wayland
<YaLTeR[m]>
I feel like if you include network latency in presentation time, mpv timing will just completely screw itself up, but idk
<YaLTeR[m]>
Since presumably it was written with the assumption that the times are mostly steady
<MrCooper>
I had similar thoughts
gryffus has joined #wayland
<daniels>
++
<daniels>
what you want to do is to keep as consistent a cadence as possible of sending the events from your local time, e.g. a faked 60Hz timer
<daniels>
keep that lined up with Pulse so the app sees one set of consistent timestamps which is shortly before you push them to the network
<daniels>
then correlate both streams on the far side so you can keep them in sync there
<daniels>
the fact that you might be +250ms from the time reported to the client is neither here nor there; what's important is that you get a consistently-timed set of streams
<colinmarc>
cool, yeah, I'm already doing the latter with video/audio PTS. that seems much simpler to implement, thanks.
<colinmarc>
I already have a 60mhz timer for encoding anyway
<kennylevinsen>
60 millihertz might be a bit too fast
<colinmarc>
heh
<colinmarc>
oops
<colinmarc>
actually maybe I will skip this protocol for now, if xwayland/mesa aren't using it. not sure why I thought they were
<colinmarc>
is there maybe unmerged work where they are using it? or is that just the new wp-commit-timing thing?
<kennylevinsen>
mesa supports for some wait-for-present functionality in the Vulkan WSI
<daniels>
yeah, it's VK_KHR_present_id / VK_KHR_present_wait, which Proton really wants to have
<daniels>
(SDL uses it as well IIRC)
<colinmarc>
SDL wayland?
mclasen has joined #wayland
<daniels>
mm, I'm mistaken, it doesn't actually use it
jlco has quit [Ping timeout: 480 seconds]
<colinmarc>
just searching online it does look like DXVK uses that extension
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
Brainium has quit []
Moprius_ has joined #wayland
Moprius_ has quit []
Moprius has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
The_Company has joined #wayland
Company has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
gryffus_ has quit [Read error: Connection reset by peer]
gryffus_ has joined #wayland
f_ has quit [Ping timeout: 480 seconds]
f_ has joined #wayland
The_Company has quit []
Company has joined #wayland
tzimmermann has quit [Quit: Leaving]
kts has joined #wayland
bodiccea_ has joined #wayland
bodiccea has quit [Ping timeout: 480 seconds]
leon-anavi has quit [Remote host closed the connection]
Brainium has quit [Quit: Konversation terminated!]
mclasen has quit [Remote host closed the connection]
coldfeet has joined #wayland
<FreeFull>
I'm trying to share a wayland socket between two different users. So far I only got it by using the same XDG_RUNTIME_DIR for both users, for some reason just symlinking the socket doesn't work
<FreeFull>
Do clients explicitly check if `$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY` is a socket file?
<FreeFull>
Ah, I figured it out, for some reason XDG_RUNTIME_DIR wasn't set at all for the second user by default
kts has quit [Ping timeout: 480 seconds]
feaneron has quit [Quit: feaneron]
rasterman has joined #wayland
gryffus has joined #wayland
gryffus_ has quit [Read error: Connection reset by peer]
gryffus has quit [Ping timeout: 480 seconds]
bodiccea_ has quit [Read error: No route to host]
bodiccea_ has joined #wayland
bodiccea has joined #wayland
gryffus has joined #wayland
bodiccea_ has quit [Ping timeout: 480 seconds]
gryffus_ has joined #wayland
Moprius has joined #wayland
gryffus has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
karenthedorf has joined #wayland
gryffus_ has quit [Read error: No route to host]
ManMower has quit [Quit: leaving]
ManMower has joined #wayland
sima has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]