ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
sevz has joined #wayland
mxz has joined #wayland
andreasbackx has quit [Ping timeout: 480 seconds]
andreasbackx has joined #wayland
andreasbackx has quit [Remote host closed the connection]
<ManMower>
a question of presentation feedback... in the sequence attach, request feedback, commit, commit (with no new buffer for the second commit), what is the expected result?
al has joined #wayland
<ManMower>
it appears that weston and mutter do this differently
<ManMower>
weston will send discarded only when a new buffer is attached (in this case, that has not happened), so the feedback request lies dormant for future stimulus
<ManMower>
mutter will consider the empty commit a replacement of the "update" and will send discarded immediately
<ManMower>
(even though the buffer may still be presented shortly)
<ManMower>
the spec doesn't really explicitly define this particular case - I'm wondering if anyone has opinions on which compositor should be treated as the reference for this?
<pq>
Personally, I'd like to go with Mutter's behaviour if possible.
<pq>
It's more clear to define a commit to always be an update regardless of what it does, than add conditions on what kind of update is a "real" update.
<pq>
But it would be funny that an empty update can cause the previously attached buffer to be "discarded" even though it may well be on screen later.
<pq>
Mutter's behaviour is more hostile towards clients that commit unnecessarily often, and I like that. :-)
<ManMower>
I've been making that extra commit intentionally because I want the compositor to kick me back that event (when paired with the commit-queue extension), and it had not occurred to me that I was using undefined behaviour
<daniels>
heh
pounce has quit [Remote host closed the connection]
<ManMower>
attach, request feedback, require buffer to be presented, commit, commit <-- currently the "require buffer to be presented" req is dropped if the surface is off screen, so the second commit will either be a nop if onscreen or force a discarded event if occluded (on mutter)
pounce has joined #wayland
<daniels>
yeah, I've always thought of no-op commits as exactly that
<pq>
That would not be reliable anyway.
<pq>
If it's off-screen, yes, you'd be guaranteed to get "discarded".
<pq>
But if it's on-screen, you could *still* get discarded.
<ManMower>
that's fine
<ManMower>
reliably getting the off screen event is the part I care about
<ManMower>
I don't care if I don't know why I got it :)
<pq>
huh
<pq>
so why not just sync?
<ManMower>
I'm pacing frames for eglSwapInterval. attach, request feedback, set timestamp, require buffer to be presented, commit, commit. wait for my feedback event to come back
<ManMower>
sync would always come back immediately
<pq>
ok, too many parts I'm unfamiliar with to say anything there :-)
<ManMower>
fair enough :)
<ManMower>
if we do endorse mutter's behaviour, does this also apply to synchronous subsurfaces? the same difference exists there - in weston we kick off the discards immediately if a new buffer is attached and a commit occurs. in mutter we kick off the discards if a commit occurs.
<pq>
yes, it applies
* ManMower
wonders how kwin handle this
<zamundaaa[m]>
KWin only sends discard if the commit contains buffer / surface damage
<pq>
interesting, three different behaviours so far
<ManMower>
surface damage! interesting
<zamundaaa[m]>
I'd be fine with changing that if there's consensus... As long as it's documented
<ManMower>
yeah, my next move will be making a wayland-protocols MR
<zamundaaa[m]>
We're clearly lacking a common definition of "content update"
<ManMower>
and we can fight about it there, bare knuckle style
<emersion>
to me, any commit is a content update
<ManMower>
that's the change I'll propose
<pq>
zamundaaa[m], indeed. Back when I wrote the spec, it was "obvious" to me that content comes in buffers. Today I'd have to disagree with my old self.
<pq>
zamundaaa[m], can you also derive semantics from that, what does it mean for frame callbacks and presentation feedback in a commit that changes nothing? When does a "no change" update become visible?
<pq>
does that ultimately mean a compositor need to do a "no-op" KMS update too, just so it can give proper presentation feedback and frame events?
<pq>
ManMower, e.g. Weston fires off frame callbacks from the repaint cycle, so at the very least repaint cycling needs to be active. I think most compositors would send frame callbacks at a specific point in a repaint cycle.
<pq>
Does this mean that a "no change" update must kick off a repaint cycle, even if it has "nothing" to do?
<ManMower>
istr a discussion many years ago about what "frame, commit" semantics should be in the absence of any actual pending changes in that commit. I do not recall the resolution of that discussion, only that it's happened before. :)
kts has joined #wayland
<pq>
I only remember that I was slightly unhappy, but that could be anything.
<pq>
If we declare that a commit is always an actual change, frame callback behavior would need to be re-checked.
<pq>
"I have not changed anything for a long time, when would be a good time to draw again?"
<ManMower>
the animated cursor use case
<pq>
Any time you want, i.e. immediately? But people wanted to use no-op commits for swap interval > 1 IIRC.
<pq>
animated cursor doesn't ring any bell for me
<ManMower>
I feel like "good time to draw" is vaguely enough defined that it's up to the compositor and nobody should assume they can implement swapinterval with it.
<pq>
I have a hazt recollection that at least "immediately" would have made people unhappy.
<ManMower>
my recollection is that I tried to pace animated cursors with long pauses by using "empty" frame/commit, and you made me use a timerfd instead
<pq>
so you'd have to kick a repaint cycle to get the usual refresh interval, or it'd never happen
<ManMower>
(which was, in retrospect, a much better way to do it)
<pq>
ManMower, that sounds very much like swap interval > 1, just without EGL.
<ManMower>
right
<pq>
so, yeah
nerdopolis has joined #wayland
garnacho has quit [Quit: garnacho]
garnacho has joined #wayland
Leopold_ has quit [Remote host closed the connection]
<zamundaaa[m]>
The compositor doesn't have to repaint, but frame callback + commit should do something reasonable. In practice, compositors send frame callbacks as if a new buffer was attached
<zamundaaa[m]>
Because Firefox uses frame callbacks with otherwise empty commits to figure out when to repaint in the near future / what the refresh rate is
JayBeeFOSS has quit [Ping timeout: 480 seconds]
<pq>
yeah, so one has to schedule a repaint and let it realize there is nothing to paint
<ManMower>
I think that case isn't relevant to presentation feedback though - I'd love to state that "when did this empty commit become visible" is meaningless
<ManMower>
(but superseding a commit with a feedback request with an empty one is meaningful)
<pq>
How do you define "empty commit"?
<ManMower>
"contains no buffer" :) which is so very lazy
<pq>
what if I change viewport without attaching anything?
<pq>
what if I change window metadata which some compositors turn into a visible change?
<pq>
like, dunno, something about SSD?
<MrCooper>
pq ManMower: FWIW, how mutter handles frame events without corresponding buffer attachment: 1) set a timer which fires at the deadline for creating a new output frame for the next refresh cycle 2) if nothing actually triggers a new frame before the timer fires, send frame events from its callback
<ManMower>
pq: then what you probably wanted was weston's current behaviour, where none of those cause the previous feedback event to be "discarded", and you just keep pacing from the feedback event you get from the last one? ;)
<pq>
MrCooper, that sounds very similar to what Weston does, except that timer is the one that runs the repaint machinery which may decide to not do much.
<pq>
ManMower, even more generally though; the previous update was shown already, and now I only change viewport and want to know when that showed up.
<pq>
arguably I am also required to set damage, so Kwin's behaviour sounds good?
<ManMower>
do you need to set damage if you change offset?
<pq>
I think one should.
<pq>
damage is always surface damage, even if it is in buffer coords
<ManMower>
mmm, yeah
<pq>
(yay)
<ManMower>
does mumble mumble ssd require damage regions? :)
<MrCooper>
if anyone knows why chromium thinks mutter's presentation feedback is buggy, would be good to know
<MrCooper>
speaking of presentation feedback, running the Element (which uses Electron/chromium AFAIK) flatpak in GNOME, it logs a lot of messages like "[3:0112/170010.906820:ERROR:wayland_frame_manager.cc(578)] The server has buggy presentation feedback. Discarding all presentation feedback requests in all frames except the last 3."
MrCooper has quit [Remote host closed the connection]
<pq>
good point - no
<ManMower>
I'd love to avoid trying to rigidly define what a "commit that doesn't actually do anything" is.
MrCooper has joined #wayland
lsd|2 has joined #wayland
<pq>
it's way too late for my Friday evening to stay here, so .o/
<ManMower>
o/
<MrCooper>
if anyone knows why chromium thinks mutter's presentation feedback is buggy, would be good to know
<ManMower>
is it using sync subsurfaces?
<MrCooper>
dunno
<ManMower>
that's really weird code that makes me wonder if they're just not dispatching events properly. heh.
* ManMower
drops hot take, closes tab
<zamundaaa[m]>
MrCooper: I get no such warnings in KWin. The message sounds like there's some old feedbacks that get neither presented nor discarded though
<ManMower>
that's my read too
Hypfer is now known as Guest13871
Hypfer has joined #wayland
Guest13871 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
<MrCooper>
hmm, do they expect the feedback to come in the same order as the corresponding requests?
<MrCooper>
*feedback events
tzimmermann has quit [Quit: Leaving]
JayBeeFOSS has joined #wayland
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
vyivel has quit [Read error: Connection reset by peer]
qyliss has quit [Quit: bye]
vyivel has joined #wayland
qyliss has joined #wayland
tent405 has joined #wayland
m0squ3ra has quit [Remote host closed the connection]
geri has joined #wayland
rasterman- has joined #wayland
rasterman has quit [Read error: Connection reset by peer]
privacy has quit [Quit: Leaving]
suntory has joined #wayland
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
riteo_ has joined #wayland
Leopold has quit [Remote host closed the connection]
riteo has quit [Ping timeout: 480 seconds]
riteo_ is now known as riteo
Leopold_ has joined #wayland
suntory has quit [Quit: leaving]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
mizvekov has joined #wayland
Leopold_ has joined #wayland
silverpower has quit [Ping timeout: 480 seconds]
abeltramo5895237 has joined #wayland
<mizvekov>
I am disappointed. I was hoping I would be able to implement my own wayland C bindings starting from the protocol XMLs, but it turns out the Vulkan WSI bindings for wayland expects libwayland objects directly, and so uses libwayland directly underneath. So we are basically stuck with libwayland.
<danieldg>
yeah, that is kinda annoying but unless you want to rewrite vulkan that's how it works
silverpower has joined #wayland
<mizvekov>
That feels like it violates the whole idea behind the XMLs in the first place.
<danieldg>
well, I guess you could have libwayland talk to an internal socket or something
<danieldg>
it does, yes
nerdopolis has quit [Ping timeout: 480 seconds]
<mizvekov>
That's not a bad idea, I would basically implement my own proxy server
<emersion>
you can still generate code for your language which uses libwayland
abeltramo589523 has quit [Ping timeout: 480 seconds]
abeltramo5895237 is now known as abeltramo589523
<danieldg>
it would be nice if the gpu libraries just handed out buffers that you could attach as needed
<emersion>
(the low-level libwayland)
<danieldg>
but it would be a lot of boilerplate passing DRM format lists to the drawing code, and feedback about what formats it actually accepts, and so forth
<mizvekov>
Yeah, would be nice if there was like a DRM vulkan wsi flavor.
<emersion>
that would be the same as no WSI
<emersion>
which is also an option but you get to rewrite a lot of finnicky code
<mizvekov>
But that is barking at the wrong tree, saying it's too much boilerplate to a vulkan developer
<emersion>
it's not boilerplate
<danieldg>
I was thinking of a theoretical "not quite libwayland" adapter API that accepts all the dmabuf-feedback and similar wayland events that vulkan needs to know about and sends them along
<mizvekov>
From some spying around with WAYLAND_DEBUG, it could do quite a lot, as it's creating it's own registry and re-enumerating all global objects again.
<ids1024>
That's not special. If you have $x libraries using Wayland, you likely end up $x calls to `get_registry`.
<mizvekov>
It seems this might be possible to do already, as there is a VK_EXT_image_drm_format_modifier which you can use to import and render to gbm buffer objects yourself.
<emersion>
mizvekov: yeah, that's what wlroots does for instance
rasterman- has quit []
<mizvekov>
By the way, on windows there is quite similar issue where the Vulkan WSI layer also sucks, and any clients that want decent performance / latency end up bypassing the Vulkan WSI layer and uses DXGI swapchain.
fmuellner has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
rv1sr has quit [Ping timeout: 480 seconds]
Brainium has quit [Ping timeout: 480 seconds]
vyivel has quit [Read error: Connection reset by peer]
geri has left #wayland [ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)]
fmuellner has joined #wayland
rv1sr has joined #wayland
vyivel has joined #wayland
Brainium has joined #wayland
rv1sr has quit []
gusnan has quit []
Leopold_ has joined #wayland
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #wayland
privacy has joined #wayland
leon has quit [Quit: Leaving]
Leopold_ has quit [Remote host closed the connection]
soreau has quit [Remote host closed the connection]
soreau has joined #wayland
soreau has quit [Read error: Connection reset by peer]
soreau has joined #wayland
soreau has quit [Read error: Connection reset by peer]