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
columbar1 has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Seirdy has quit [Quit: exiting 3.3-dev]
<zebrag>
Xeyes for wayland? Weyes?
<danieldg>
zebrag: one of the benefits of wayland is that random applications can't track your mouse cursor
<pq>
How annoying. I'm certain I have commented in Gitlab "we can't fix games" and swick responded to that "maybe we can" referring to changes in Mesa + a Wayland extension, but I can't find this discussion anywhere.
<swick>
but I don't think anyone has written the patch for it
<swick>
and the other one being games which really don't like changing refresh cycles which probably requires a special mode in the WSI
<swick>
which basically ignores all timing information from the compositor and does its own thing. handling swapchain backpressure will be the interesting part there
<swick>
if all those games are windows based that code could be moved to the translation layers
<pq>
I think we can pretty confidently say that no-one makes commercial games for Wayland, so...
Erandir has quit [Read error: Connection reset by peer]
<pq>
but if you do, please shout! :-)
xexaxo has joined #wayland
pochu has quit [Ping timeout: 480 seconds]
aleasto has joined #wayland
xexaxo has quit [Ping timeout: 480 seconds]
audgirka has quit [Quit: Leaving]
flacks has quit [Quit: Quitter]
flacks has joined #wayland
apol[m] has joined #wayland
arichardson[m] has joined #wayland
test has joined #wayland
charafau[m] has joined #wayland
Eighth_Doctor has joined #wayland
danburd[m] has joined #wayland
DasChaos[m] has joined #wayland
Guest992 has joined #wayland
GeorgesStavracasfeaneron[m] has joined #wayland
freshgumbubbles[m] has joined #wayland
gnustomp[m] has joined #wayland
go4godvin has joined #wayland
heftig[m] has joined #wayland
Guest1032 has joined #wayland
inkbottle[m] has joined #wayland
junglerobba[m] has joined #wayland
jryans has joined #wayland
kajiryoji[m] has joined #wayland
Levans has joined #wayland
mooff has joined #wayland
niecoinny[m] has joined #wayland
ongy[m] has joined #wayland
pac85[m] has joined #wayland
psydroid[m] has joined #wayland
rails[m] has joined #wayland
robertmader[m] has joined #wayland
Sumera[m] has joined #wayland
toggleton[m] has joined #wayland
YaLTeR[m] has joined #wayland
pnowack has joined #wayland
<swick>
oh, I didn't know about vsync-feedback. I was literally working on a latching feedback protocol right now
<pq>
heh, yeah, it was several years back it was last... anywhere, I think
leon-p has quit [Quit: leaving]
<swick>
so, what I'm doing differently is just sending timestamps every time the compositor is latching on to content instead of having a fixed interval which might change
pochu has joined #wayland
<swick>
also sending MSC which I think will help for Xwayland (MrCooper?) and could be used to identify a latching event in the presentation feedback protocol
<swick>
throttling would basically be a hint: draw for every n-th latching event
<pq>
what's your definition of "compositor latching"?
<pq>
MSC is a good point
<pq>
one of the design goals of vsync-feedback was that the compositor does not need to send events every vblank, and it doesn't even need to spin KMS flips or do anything every blank if there is no damage to be posted.
psydroid[m] has quit []
ammen99[m] has quit []
mooff has quit []
test has quit []
<swick>
latching happens when the compositor takes a commit from a surface to produce the next presentation
<swick>
in VRR mode you're forced to always send an event anyway and even then you have clock drift
<pq>
yeah, vsync-feedback is explicitly for fixed-rate, which is what apps depending on it expect too
<swick>
the throttle event with a special value of zero would act as surface suspension where it would be valid to not send the latching events anymore
<pq>
is the latching feedback supposed to be some kind of deadline prediction tool, or what's the use case?
<swick>
also, yes
<swick>
i.e. I want to be able to implement VK_GOOGLE_display_timing with it
<pq>
Could a compositor latch twice in a refresh cycle? E.g. on composite-bypass? hm, but KMS does not allow replacing commits for now.
<swick>
and hopefully make Xwayland present work better but I don't know enough about that right now
<swick>
if you produce two presentations with tearing in one refresh cycle there would be two latching events
<swick>
okay, composite-bypass will need some more thinking
pochu has quit [Remote host closed the connection]
pochu has joined #wayland
<swick>
actually only the tearing composite-bypass
<zamundaaa>
Only tearing + windowed operation matters
<zamundaaa>
direct scanout is irrelevant
<zamundaaa>
But it's the same problem either way
<swick>
well, if a surface is in composite-bypass mode and commits a tearing update that the compositor then presents with tearing that would, with my previous definition of latching, be a latching event
<swick>
but that event would be actively harmful because it would destroy your deadline calculations
<swick>
the latching events would have to be restricted to non-tearing latching
<zamundaaa>
Yeah. I guess there's only two options: Let the compositor fake vsync rendering with a timer, or have the client handle the situation
<zamundaaa>
Stopping to send events is likely gonna screw up clients. They should still continue rendering, even if presentation is not actually vsynced
pochu has quit [Ping timeout: 480 seconds]
<zamundaaa>
That gets me thinking though... At least in theory it should be possible to have one client tear and others on the same screen VSync.
<zamundaaa>
Probably not relevant for the protocol though
<swick>
even if a surface is committing tearing updates the compositor could try to latch on to a commit to present non-tearing for the next scanout cycle
<swick>
i.e. the compositor still has a latching event where it looks for a non-tearing commit even if there was a tearing commit this cycle
<swick>
in other words: only latching events which are latching onto non-tearing commits will be send
<pq>
swick, are you defining the extension based on what the compositor can say, or what the client needs to know?
<swick>
what the client needs to know
<pq>
ok, good
Guest992 has quit []
heftig[m] has quit [Quit: Client limit exceeded: 10000]
<zamundaaa>
swick: yeah that could work. It's not ideal but tearing + windowed mode is generally not ideal... and if necessary faking vsync events is always a possibility
jryans has quit []
Eighth_Doctor has quit []
NoGuest17 has quit [Remote host closed the connection]
NoGuest17 has joined #wayland
<swick>
"deadline for a buffer to become ready to hit the next refresh cycle without tearing" is probably a much better description than the latching thing
<pq>
s/to hit/to show on/ perhaps?
<swick>
yeah
st3r4g has quit [Quit: おやすみ]
st3r4g has joined #wayland
<swick>
when the commits of a surface controlls vrr though there is no single deadline and afaik userspace is not told the "deadline range" of the following cycle
<romangg>
pq: ty, hope you like the post and also that my comparison with libweston is fair.
kajiryoji[m] has quit []
<pq>
romangg, I'd say your assesment of libweston is even exceedingly nice. :-)
<romangg>
haha, I might have a soft spot for it because I read a lot of daniels DRM code in Weston back in the days when trying to understand how atomic mode setting works. Without it I would have been *lost*.
<daniels>
I've always thought of myself as an influencer
<pq>
romangg, that's the insides - have you ever looked at the frontend? compositor/main.c?
<romangg>
daniels: I mean purely optically I can easily imagine you on some tropical beach advertising surf boards or so via instagram. :P
<romangg>
pq: I don't think so. Is it way different?
<pq>
you can start if from anything you want, but starting from 1 is supposed to work, or something else was messed up
<pq>
ah, dependent interfaces
<pq>
yeah, in that case it is logical to start with version 15
<pq>
and for consistency, I'd also put since=15 in all the messages
<zzag>
pq: aha, gotcha
<zzag>
thanks!
<pq>
I wonder, are we in trouble if org_kde_plasma_window_management.destroy request and org_kde_plasma_window_management.activation race against each other?
<pq>
...wait, is there no destroy request at all?
remanifest has quit [Remote host closed the connection]
remanifest has joined #wayland
<pq>
whoa, that's really creative in getting bitmask values into an enum :-o
<pq>
I guess it works in C and C++.
<MrCooper>
swick: latching feedback should be useful in its own right, but it probably won't make a big difference for Xwayland Present support, since Xwayland needs to send out MSC events without any corresponding presentation
<MrCooper>
swick: for the latching feedback, note that there are two separate deadlines (which may be the same in some cases though): 1) when the compositor needs to have the buffer 2) when the GPU needs to have finished drawing to the buffer
flibitijibibo has quit [Quit: Leaving]
<romangg>
MrCooper: Ah, since you're here at the moment. I got your message about https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/675. Quite a lot of refactoring work, but I guess it makes sense to remove the abstraction if there is no other consumer. What interface remains in the Present code that xwl uses?
<MrCooper>
just the screen hooks that SCMD uses as well
<romangg>
wow, that's a slim interface. would have thought it needs more. kudos.
xexaxo has joined #wayland
<MrCooper>
thanks, WNMD didn't need more to hook up though :)
saumon has quit [Remote host closed the connection]
saumon has joined #wayland
<swick>
MrCooper: the protocol would send the information unconditionally; no commit required
<swick>
the two deadlines are a really interesting point though
silver has quit [Ping timeout: 480 seconds]
<pq>
I got my monitor to acknowledge ST 2084 mode as HDR, yay. But it's very dark.
saumon has quit [Quit: Leaving server]
<pq>
it claims to support "traditional gamma, HDR" too, but does not ack that as HDR
saumon has joined #wayland
<pq>
next: bump max_bpc from 8 to 16, and play with the metadata (now it's all zeroes)
<pq>
till next week \o.
<swick>
nice!
<swick>
still want a HDR monitor to experience some of that fun
saumon has quit []
saumon has joined #wayland
aleasto has quit [Remote host closed the connection]
<MrCooper>
swick: how would the events be triggered then: one event per request, or one request each to start/stop events?
psychon has left #wayland [#wayland]
<swick>
request to create an object which continously delivers events
MrCooper has quit [Remote host closed the connection]
zebrag has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #wayland
NoGuest17 has quit [Remote host closed the connection]
NoGuest17 has joined #wayland
leon-p has joined #wayland
MrCooper has joined #wayland
tzimmermann has quit [Quit: Leaving]
<MrCooper>
swick: while that should be sufficient for Xwayland Present, it could be wasteful when the events aren't actually needed? How about a request which triggers one event for a target MSC, which provides the current MSC (for when the target is in the past), corresponding timestamp, plus any needed latching info?
<MrCooper>
though this would definitely require the compositor to provide a monotonic MSC, even if the surface moves between outputs
<swick>
how would you know you didn't miss anything then?
<swick>
ohh, the MSC, right
<swick>
good idea actually
hegstal has quit [Ping timeout: 480 seconds]
remanifest has quit []
remanifest has joined #wayland
NoGuest17 has left #wayland [#wayland]
Lyude has joined #wayland
immibis is now known as Guest1077
immibis has joined #wayland
Guest1077 has quit [Ping timeout: 480 seconds]
silver has joined #wayland
remanifest has quit [Remote host closed the connection]
creich has joined #wayland
creich is now known as Guest1081
zebrag has quit [Remote host closed the connection]
Guest1081 has quit []
zebrag has joined #wayland
remanifest has joined #wayland
remanifest has quit [Remote host closed the connection]