00:35 wlb: wayland-protocols Merge request !272 opened by Xaver Hugl (Zamundaaa) staging: add ext-blur-v1 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/272
05:14 vincejv: any reliable vnc server working on wayland?
05:15 vincejv: nvm i forgot ill just use google
11:51 wlb: weston/main: Robert Mader * backend-drm: Don't force non-opaque overlays to primary plane https://gitlab.freedesktop.org/wayland/weston/commit/5a2509ffb1e0 libweston/backend-drm/state-propose.c
11:51 wlb: weston Merge request !1443 merged \o/ (backend-drm: Don't force non-opaque overlays to primary plane https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1443)
13:01 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?
13:01 ManMower: it appears that weston and mutter do this differently
13:01 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
13:02 ManMower: mutter will consider the empty commit a replacement of the "update" and will send discarded immediately
13:02 ManMower: (even though the buffer may still be presented shortly)
13:03 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?
13:04 pq: Personally, I'd like to go with Mutter's behaviour if possible.
13:05 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.
13:06 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.
13:07 pq: Mutter's behaviour is more hostile towards clients that commit unnecessarily often, and I like that. :-)
13:08 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
13:08 daniels: heh
13:09 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)
13:12 daniels: yeah, I've always thought of no-op commits as exactly that
13:12 pq: That would not be reliable anyway.
13:13 pq: If it's off-screen, yes, you'd be guaranteed to get "discarded".
13:13 pq: But if it's on-screen, you could *still* get discarded.
13:13 ManMower: that's fine
13:13 ManMower: reliably getting the off screen event is the part I care about
13:14 ManMower: I don't care if I don't know why I got it :)
13:14 pq: huh
13:14 pq: so why not just sync?
13:17 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
13:17 ManMower: sync would always come back immediately
13:20 pq: ok, too many parts I'm unfamiliar with to say anything there :-)
13:21 ManMower: fair enough :)
13:23 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.
13:23 pq: yes, it applies
13:25 ManMower:wonders how kwin handle this
13:32 zamundaaa[m]: KWin only sends discard if the commit contains buffer / surface damage
13:32 pq: interesting, three different behaviours so far
13:32 ManMower: surface damage! interesting
13:33 zamundaaa[m]: I'd be fine with changing that if there's consensus... As long as it's documented
13:33 ManMower: yeah, my next move will be making a wayland-protocols MR
13:33 zamundaaa[m]: We're clearly lacking a common definition of "content update"
13:33 ManMower: and we can fight about it there, bare knuckle style
13:34 emersion: to me, any commit is a content update
13:34 ManMower: that's the change I'll propose
13:35 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.
13:42 wlb: weston/main: Zhou Liang * backend-drm: fix drm find wrong connector https://gitlab.freedesktop.org/wayland/weston/commit/8b3becf524ac libweston/backend-drm/ drm-internal.h drm.c kms.c
13:42 wlb: weston/main: Zhou Liang * backend-drm: fix drm add connector to unexpected drm device https://gitlab.freedesktop.org/wayland/weston/commit/66aaa41074f5 libweston/backend-drm/drm.c
13:42 wlb: weston/main: Zhou Liang * backend-drm: fix deinit unexpected connector https://gitlab.freedesktop.org/wayland/weston/commit/b288e662d6be libweston/backend-drm/drm.c
13:42 wlb: weston Merge request !1428 merged \o/ (backend-drm: fix drm find wrong connector https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1428)
13:43 zamundaaa[m]: Yeah. Going with commits as "content update" is the safest option
13:47 vyivel: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/36 agrees with this
13:50 wlb: weston Merge request !1424 merged \o/ (compositor: improve viewport source validity check https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1424)
13:50 wlb: weston/main: Chao Guo * compositor: improve viewport source validity check https://gitlab.freedesktop.org/wayland/weston/commit/8e0e75999ed8 libweston/compositor.c
13:52 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?
13:54 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?
14:02 ManMower: hmm, why do frame callbacks care?
14:26 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.
14:26 pq: Does this mean that a "no change" update must kick off a repaint cycle, even if it has "nothing" to do?
14:30 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. :)
14:32 pq: I only remember that I was slightly unhappy, but that could be anything.
14:33 pq: If we declare that a commit is always an actual change, frame callback behavior would need to be re-checked.
14:33 pq: "I have not changed anything for a long time, when would be a good time to draw again?"
14:34 ManMower: the animated cursor use case
14:35 pq: Any time you want, i.e. immediately? But people wanted to use no-op commits for swap interval > 1 IIRC.
14:35 pq: animated cursor doesn't ring any bell for me
14:36 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.
14:36 pq: I have a hazt recollection that at least "immediately" would have made people unhappy.
14:37 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
14:37 pq: so you'd have to kick a repaint cycle to get the usual refresh interval, or it'd never happen
14:38 ManMower: (which was, in retrospect, a much better way to do it)
14:38 pq: ManMower, that sounds very much like swap interval > 1, just without EGL.
14:38 ManMower: right
14:38 pq: so, yeah
15:41 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
15:42 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
15:53 pq: yeah, so one has to schedule a repaint and let it realize there is nothing to paint
15:53 wlb: wayland-protocols Merge request !273 opened by Derek Foreman (derekf) presentation-time: Clarify what a content update is https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/273 [presentation-time]
15:54 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
15:54 ManMower: (but superseding a commit with a feedback request with an empty one is meaningful)
15:55 pq: How do you define "empty commit"?
15:56 ManMower: "contains no buffer" :) which is so very lazy
15:56 pq: what if I change viewport without attaching anything?
15:58 pq: what if I change window metadata which some compositors turn into a visible change?
15:58 pq: like, dunno, something about SSD?
15:58 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
15:59 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? ;)
16:00 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.
16:02 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.
16:03 pq: arguably I am also required to set damage, so Kwin's behaviour sounds good?
16:03 ManMower: do you need to set damage if you change offset?
16:04 pq: I think one should.
16:04 pq: damage is always surface damage, even if it is in buffer coords
16:04 ManMower: mmm, yeah
16:04 pq: (yay)
16:05 ManMower: does mumble mumble ssd require damage regions? :)
16:06 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."
16:06 MrCooper: if anyone knows why chromium thinks mutter's presentation feedback is buggy, would be good to know
16:06 pq: good point - no
16:06 ManMower: I'd love to avoid trying to rigidly define what a "commit that doesn't actually do anything" is.
16:07 pq: it's way too late for my Friday evening to stay here, so .o/
16:07 ManMower: o/
16:08 MrCooper: if anyone knows why chromium thinks mutter's presentation feedback is buggy, would be good to know
16:09 ManMower: is it using sync subsurfaces?
16:10 MrCooper: dunno
16:15 ManMower: that's really weird code that makes me wonder if they're just not dispatching events properly. heh.
16:15 ManMower:drops hot take, closes tab
16:18 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
16:18 ManMower: that's my read too
16:40 MrCooper: hmm, do they expect the feedback to come in the same order as the corresponding requests?
16:40 MrCooper: *feedback events
21:12 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.
21:13 danieldg: yeah, that is kinda annoying but unless you want to rewrite vulkan that's how it works
21:16 mizvekov: That feels like it violates the whole idea behind the XMLs in the first place.
21:16 danieldg: well, I guess you could have libwayland talk to an internal socket or something
21:16 danieldg: it does, yes
21:17 mizvekov: That's not a bad idea, I would basically implement my own proxy server
21:17 emersion: you can still generate code for your language which uses libwayland
21:17 danieldg: it would be nice if the gpu libraries just handed out buffers that you could attach as needed
21:17 emersion: (the low-level libwayland)
21:18 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
21:18 mizvekov: Yeah, would be nice if there was like a DRM vulkan wsi flavor.
21:19 emersion: that would be the same as no WSI
21:19 emersion: which is also an option but you get to rewrite a lot of finnicky code
21:19 mizvekov: But that is barking at the wrong tree, saying it's too much boilerplate to a vulkan developer
21:20 emersion: it's not boilerplate
21:23 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
21:31 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.
21:33 ids1024: That's not special. If you have $x libraries using Wayland, you likely end up $x calls to `get_registry`.
21:34 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.
21:35 ids1024: https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer is an attempt at implementing the Vulkan WSI as a layer, including Wayland support. The project doesn't seem very active though.
21:36 emersion: mizvekov: yeah, that's what wlroots does for instance
21:39 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.