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 quit [Ping timeout: 480 seconds]
columbar1 has joined #wayland
columbar1 has quit [Ping timeout: 480 seconds]
hegstal has quit [Remote host closed the connection]
silver has quit [Ping timeout: 480 seconds]
silver has joined #wayland
boistordu has quit [Ping timeout: 481 seconds]
pH5 has quit [Remote host closed the connection]
pH5 has joined #wayland
onelegend has joined #wayland
sih has joined #wayland
aquijoule_ has joined #wayland
richbridger has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
tzimmermann has quit [Remote host closed the connection]
tzimmermann has joined #wayland
dcz has joined #wayland
hardening has joined #wayland
sih has quit [Remote host closed the connection]
danvet has joined #wayland
pH5 has quit [Remote host closed the connection]
letoram has quit [Remote host closed the connection]
letoram has joined #wayland
pochu has joined #wayland
pH5 has joined #wayland
pnowack has joined #wayland
pnowack has quit [Remote host closed the connection]
pnowack has joined #wayland
immibis has joined #wayland
audgirka has joined #wayland
johnjay has quit [Ping timeout: 480 seconds]
johnjay has joined #wayland
bodiccea_ has joined #wayland
bodiccea has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
txtsd has joined #wayland
columbar1 has joined #wayland
columbar1 has quit [Ping timeout: 480 seconds]
GreatGodvin has joined #wayland
flacks has quit [Quit: Quitter]
flacks has joined #wayland
audgirka_ has joined #wayland
audgirka has quit [Ping timeout: 480 seconds]
columbar1 has joined #wayland
irbehe has joined #wayland
irbehe has quit []
audgirka__ has joined #wayland
audgirka_ has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
columbar1 has quit [Ping timeout: 480 seconds]
<MrCooper>
if when the compositor processes an output frame, there has been only one commit for one of the surfaces, which contains only a presentation-time feedback request, is the corresponding presented event sent?
<MrCooper>
what if the compositor does not need to draw anything or make any other output changes?
<emersion>
from my reading of the protocol, yes
<emersion>
same applies to a commit which only has a wl_surface.frame
<pq>
The situation implied by that question is infuriating: a client abusing protocol or being plain stupid, most likely in lack of a protocol extension that would actually provide them what they need. :-/
<pq>
If there is no damage with the commit asking for feedback, one could as well just send "presented" immediately with the timestamp of the previous actual update. But that's just more code in a compositor to come up with trolling answer.
<pq>
hm, equally well one could just send "discarded"
<pq>
if there is literally nothing else updated than just asking for feedback
<emersion>
you need to be absolutely sure that none of the surface state (incl extensions) has changed to troll the client like this
<pq>
yup
<emersion>
"discarded" means superseded by another update, not sure it's right here
<pq>
so best is to just do the simple thing: make sure the compositor will repaint and KMS flip, even if there is nothing to change, and send feedback when that completes.
<emersion>
maybe the protocol wording allows it, if it doesn't specify that the other update must be in the future
GreatGodvin has quit [Remote host closed the connection]
GreatGodvin has joined #wayland
GreatGodvin has quit [Quit: WeeChat 3.2]
<MrCooper>
pq: the compositor could use a vblank event instead of a needless repaint & flip; I don't see any code for either in mutter though, are other compositors doing either?
<MrCooper>
if Xwayland could rely on this, it would make using presentation-time for X11 Present MSC/timestamp values easier
<pq>
MrCooper, dunno, I suppose no-one has asked this question before.
<pq>
maybe there should be an extension to solve your original problem instead of bending existing extensions to do something vaguely similar sometimes?
<emersion>
is a no-op flip a big deal?
<emersion>
the repaint should be a no-op since damage is empty
<emersion>
vblank events are so messy i wouldn't try to use these
<emersion>
drmCrtcQueueSequence is a bit better
<zamundaaa>
Firefox relies on empty commits giving frame callbacks for VSync already but yeah that's really not a good solution
<zamundaaa>
I know that KWin schedules frames on empty commits exactly for that. Mutter probably does, too, or the Firefox vsync option would be broken
<zamundaaa>
I just mean that clients fake-presenting a frame, waiting for the fake-present to be through (so waiting at least one refresh period) and then having to guesstimate the future VSync timings is a bad design
<MrCooper>
unfortunately, it's what Xwayland has to work with
<MrCooper>
if it can't always get timings from the compositor, it has to extrapolate for X11 clients
<pq>
The way you say it sounds like you don't believe there will ever be a proper solution so you want to standardise a workaround now.
<MrCooper>
I'm afraid I'm not really motivated to create a new extension for this
<pq>
Ok, but my opinion is still: please do not abuse frame callbacks or presentation-time feedback.
<pq>
but if you insist, then at least abuse them right and make some damage to go with it
<pq>
that way there is no need to wonder how all compositors behave
<MrCooper>
heh, "abuse right" :)
<pq>
:-P
<zamundaaa>
pq: I don't think it's an issue in practice anymore, with Firefox already doing it without damage
agd5f has quit [Remote host closed the connection]
* swick
whispers present-timing
<swick>
lots of people seem to abuse both the frame callback and the presentation feedback on both compositors and clients because we're simply missing frame scheduling and latching feedback
<swick>
yeah, I noticed they uploaded the talks but have not watched them yet
<pq>
you can *read* them, they seem to have full transcriptions
<swick>
that's neat
<pq>
which is something at least I prefer very much
<zamundaaa>
swick: you still have to submit a frame and wait for its presentation with present-timing (in its current state) though, right?
<MrCooper>
swick: frame scheduling & latching feedback won't help when an X11 client asks for the current MSC & timestamp (or a future one with no corresponding content update)
<swick>
zamundaaa: no, the client would do all waiting on its own and use the feedback to adjust its own waiting
rgallaispou has quit [Remote host closed the connection]
<swick>
waiting for presentation feedback gives you no guarantee other than the update was either discarded or displayed which is not useful at all for scheduling your frames
rgallaispou has joined #wayland
<swick>
MrCooper: I think it does. You get the latching feedback and estimate from those past latching events when the next one is going to happen. each latching event increases the MSC and the estimated latching event is the timestamp.
<pq>
swick, thanks!
<zamundaaa>
swick: it's not only about frame scheduling, it's about knowing when your frame will be presented in advance - which you only have a ballpark estimate for if you schedule the frame for a given time because of the fixed time intervals (... that, on first present, the client also has no clue about)
<pq>
MrCooper, did you know there was a draft of a vblank/msc tracking protocol extension which works without sending an event every vblank?
<zamundaaa>
So browsers would use that future time to pace their animations, videos and whatever to perfectly fit the VSync timing
<MrCooper>
pq: yeah, though I'd forgotten about it, saw it again in my e-mail today
<swick>
zamundaaa: right, but for that you have the presentation feedback
<pq>
MrCooper, oh you have a copy, cool - I would not have known where to search :-D
<zamundaaa>
swick: presentation feedback doesn't work without submitting a frame first, and waiting for its completion
<zamundaaa>
If you assume that the client hasn't presented any frames for a bit then the first frame when resuming rendering will either be timed badly or delayed by a frame
<swick>
zamundaaa: sure, but when you scheudle a frame for time N and it gets presented at time M you have an estimate for how long it takes for a frame to reach the eyes of the user that you can apply for all future scheduled frames
<swick>
no, why would it?
<zamundaaa>
swick: yes, but that doesn't really improve anything vs presentation-timing
<zamundaaa>
well, if you don't know what the VSync times are - because of VRR, timer resolution or whaterver - then you either have to submit a frame targeting a randomly chosen time which most likely doesn't directly hit a vsync timing, or you have to submit an empty frame, and then submit the next frame afterwards
<swick>
I feel like I'm missing something
<zamundaaa>
Think about the first presented frame (client was hidden for a while, hasn't presented anything yet at all, sth like that)
<swick>
yeah, if you don't submit new frames your estimated timings and the real timings get further and further away
<zamundaaa>
That's why there would ideally be a protocol that clients can use to ask the compositor about the next vblank timing
<zamundaaa>
Or last vblank timing + next frame info (for VRR)
<swick>
I see
<swick>
so the latching data should be send regardless of content updates
<swick>
or the compositor creates the estimates
<swick>
but I don't see why the compositor should do that when the client can do too
<zamundaaa>
yeah the compositor should ideally create the estimate
<zamundaaa>
The client can't if it doesn't have the last frame timing
<swick>
yeah, but we could send them
<swick>
but I see your point now. latching feedback should not require content updates.
<zamundaaa>
Yeah. For example present-timing could have a request where clients can ask the compositor "if I submitted a frame with that target time, what time would the frame most likely actually be presented / seen by the user"
<zamundaaa>
It can't always work because of VRR etc of course but I think that could be useful. Together with "at what time does the frame need to be submitted / ready to still hit that target time"
<pq>
zamundaaa, a couple of details: you'd also have to ask for a specific output. You don't know which output your window is going to until the window has content and is mapped.
<pq>
the other details is that the request should be formulated in a way to avoid clients needing to ask multiple times
<swick>
I would argue that this has to be per surface
<pq>
yes, and per surface there is no answer until the surface is visible so it is known which output it syncs to
<swick>
right, more reason to just send the latching feedback and let the client estimate
<pq>
but maybe that can be mitigated, xdg-shell has the issue with creating an initially-fullscreen window too
<zamundaaa>
swick: the client knows even less than the compositor which output the surface will land on
<zamundaaa>
...at least most the time
<pq>
after the surface is mapped, the client knows pretty much the same as the compositor
<pq>
but before it doesn't
<zamundaaa>
with the surface suspension protocol etc this could get more complicated (?) but I guess we could assume for the very initial presentation when the window gets created that the timing doesn't matter
<swick>
estimating things in the compositor means different compositors will differently estimate things which means clients might work really well on one and not well at all on another
agd5f has quit [Read error: Connection reset by peer]
<swick>
i'm convinced that doing any kind of guesswork in the compositor will result in horrible things
agd5f has joined #wayland
<swick>
it's the same reason I really don't like that people are trying to schedule the frame callback as close as possible to the latching event with the client still hitting it
<pq>
btw. about timings, there is an interesting question in https://gitlab.freedesktop.org/wayland/weston/-/issues/514 - can one do zero-copy from guest compositor to host display via qemu and guest KMS while still maintain full framerate.
<MrCooper>
... with only 2 buffers? (Should be easy given enough buffers :)
<MrCooper>
even with 2 it should be possible in theory, though it may depend on how the host releases buffers
audgirka has quit [Quit: Leaving]
yoslin has quit [Quit: WeeChat 3.2]
yoslin has joined #wayland
Lucretia has quit []
Lucretia has joined #wayland
pochu has quit [Ping timeout: 480 seconds]
cedric has joined #wayland
cedric is now known as bluebugs
zebrag has quit [Quit: Konversation terminated!]
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
<dottedmag>
How is DRM_IOCTL_CRTC_QUEUE_SEQUENCE used? I don't see it in wlroots or Weston, and see a usage in Xserver, but it looks like this ioctl is abused there to get the "next frame sequence" instead of actually queueing an event and reading it.
<dottedmag>
Ah, I see it in Mesa.
tzimmermann has quit [Quit: Leaving]
mixfix41_ has joined #wayland
mixfix41 has quit [Ping timeout: 480 seconds]
<emersion>
dottedmag: yeah it's been introduced for the purposes of the vulkan wsi
<emersion>
there is drmModeGetSequence which just queries the current one
<emersion>
maybe that's routed to the same IOCTL with a flag or something