07:34wlb: weston Merge request !1189 opened by Daniel van Vugt (vanvugt) clients/simple-dmabuf-feedback: Remove unsupported f suffixes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1189
09:14MrCooper: pq: snap, you beat me by a minute :)
09:18wlb: weston Merge request !1190 opened by Marius Vlad (mvlad) libweston: Skip views without a parent https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1190 [Core compositor]
09:34pq: swick[m], if there is a definition that exactly matches what we want, I think we should probably use that.
09:35pq: swick[m], do those explain how to interpret mastering display parameters?
09:36pq: i.e. the change in adapted white point or not
09:45jadahl: pq: I don't think I ever heard "front porch" as a term describing something mode setting related before :P
09:46pq: oh? It's a standar part of video timings diagram.
09:46jadahl: i must have missed that one
09:47pq: here's a random web page with some diagrams: https://web.mit.edu/6.111/www/s2004/NEWKIT/vga.shtml
09:49pq: hmm, or did I confuse sync vs. blank?
09:50pq: looking at https://electronics.stackexchange.com/questions/166681/how-exactly-does-a-vga-cable-work maybe I did
09:52wlb: weston/main: Daniel van Vugt * clients/simple-dmabuf-feedback: Remove unsupported f suffixes https://gitlab.freedesktop.org/wayland/weston/commit/183d92e29151 clients/simple-dmabuf-feedback.c
09:52wlb: weston Merge request !1189 merged \o/ (clients/simple-dmabuf-feedback: Remove unsupported f suffixes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1189)
11:04kennylevinsen: pq: It doesn't help that vsync is at times misused to refer to synchronization with vblank :)
11:06emersion: i'm not sure that's a mis-use tbh
11:07emersion: you can see it the other way: vsync is misused to refer to the vertical sync pulse
11:12pq: vsync *is* the vertical sync pulse
11:13pq: but yeah, I guess UIs use the same word for "do not tear and do not drop frames" or something
11:13pq: that's actually the rule rather than exception
11:14pq: but when the talk context is video timings, sync pulse prevails
11:16pq: the sync pulse existed first
11:17emersion: hm
11:24vsyrjala: with vga/etc. actual vsync status bit is all you got, so it was also used to do the rendering vs. scanout synchronization
11:24vsyrjala: that is presumably the source of the overlapping terminology
11:58swick[m]: pq: nope, it's as vague about the mastering display color volume as all the other documents
12:02pq: pfft
12:03JEEB: 99% of that is like display p3 and 1000 to 4000 nits I think?
12:04JEEB: "calibrated to this gamut and eotf with clip at xyz nits"
12:04pq: JEEB, we have the parameters, but we don't know if one must do white point adaptation or not when converting to/from the masteering display space.
12:05JEEB: i think technically yes, but no-one thought of mentioning it explicitly since in the vast majority of cases it happens to match
12:05JEEB: since white point is part of primaries
12:06JEEB: i would prefer if that was written somewhere that the relevant folks thought of it
12:07JEEB: or oooh we totally didn't think of it, let's see
12:07pq: the whole question started from "why does ST 2086 metadata carry also white point"
12:07JEEB: it's part of the primaries' definition so carrying it is just the default you do, I think?
12:08JEEB: but yea will see if I can find anything historical
12:08pq: sure, I'd do that too
12:08pq: but if you carry it, it can differ from the white point of the encoding space, so what do I do then
12:11pq: all this is just an effort trying to understand how the mastering display parameters define the mastering display color volume, and how to translate that volume into the container/encoding space.
12:11pq: which is a few steps away from using those parameters to guide gamut and tone mapping
14:20wlb: weston Issue #730 opened by Colin Kinloch (ColinKinloch) assert fails for subsurface with destroyed parent https://gitlab.freedesktop.org/wayland/weston/-/issues/730
14:41heeen: can you resolve an id to a wl_resource
14:46kennylevinsen: heeen: client or server?
14:46heeen: server
14:46kennylevinsen: wl_client_get_object does that
14:47heeen: are resource ids unique in the server?
14:47heeen: I forgot if they are client supplied or server
14:47kennylevinsen: supplied by client and scoped as such
14:47kennylevinsen: hence it being tied to struct wl_client
14:48heeen: so an id also needs the client this resource belongs to to identify the resource?
14:48kennylevinsen: yes, an IDs only make sense in the context of the client that made it
14:49heeen: is there an id within the server that uniquely identifies resources across clients? apart from the memory address of the wl_resource
14:49kennylevinsen: no
14:52heeen: do clients have an id
14:52kennylevinsen: you also normally do not resolve resources from ids yourself, as the server protocol implementation did it for you in its callbacks
14:52kennylevinsen: clients have a wl_client struct
14:53heeen: I am trying to write a DBus API that references shell surfaces and other resources
14:53heeen: so my naive idea was to just use resource ids, but I forgot those were client supplied and not unique globally
14:54heeen: so I suppose I need to create my own key, like an incrementing Id or something
14:54kennylevinsen: look at xdg-foreign-unstable
14:54heeen: thanks
14:55kennylevinsen: the way it gives surfaces a token is probably similar to what you will need
14:56kennylevinsen: (maybe the same token, or at least the way of storing it can be reused in the compositor you are implementing it in)
14:56heeen: may be a bit heavyweight for me. In my usecase the taskswitch component in the compositor would publish all surfaces and some service could request to switch to a given app surface
14:57kennylevinsen: you could start by publishing the xdg-toplegel app IDs
14:58kennylevinsen: the task switcher would likely want to know those anyway
14:59kennylevinsen: but for identifying every individual toplevel you'd likely want a randomized string token that the compositor generates and stores with the toplevel
15:03heeen: we're not implementing xdg anything I think
15:03heeen: unless qt does that under the hood
15:04heeen: we have our own shell extension, own shell surfaces
15:05kennylevinsen: well potato tomato, for whatever your toplevel-ish shell surface is you would store a random string token for later reference
15:08swick[m]: MrCooper: > Not really. We normally still want to aim for start of vblank with VRR, which would result in the maximum refresh rate. Missing that target just incurs less of a penalty than with fixed refresh rate.
15:08swick[m]: that's not really the case in a lot of situations though, is it?
15:08swick[m]: playing a video at n25fps, games running at n30fps, etc
15:10MrCooper: right now there's no mechanism for clients to communicate that to the compositor, so it has to assume the target is ASAP
15:10swick[m]: ahh, I see where you're coming from
15:12swick[m]: but also from a compositor POV if we only want to commit buffers which are ready and we use start of vblank as a deadline you effectively have no vrr anymore
15:12JEEB: pq: regarding reference viewing environment the "grading HDR content" video referenced BT.2408 , which in turn refers to BT.2100, which defines a neutral grey at D65 with range of at least [0.005-1000 nit] at a surround light of 5 nits. keyword is "reference viewing environment"
15:12swick[m]: it only works if we commit buffers which are potentially not ready
15:13MrCooper: swick[m]: why? buffers may become ready only after start of vblank
15:13MrCooper: then the compositor can push out the next frame ASAP
15:14pq: JEEB, yeah, BT.2100 has that definition. What are we talking about?
15:14MrCooper: which results in refresh rate somewhere in the VRR range
15:15swick[m]: MrCooper: mh, what exactly are we talking about? direct scanout or composited VRR?
15:15JEEB: pq: mostly since I recalled recent stuff noting that as the reference against which then one's output should be adjusted (in case you have your brightness etc known). just decided to throw that out there since I also noticed that reference viewing environment being mentioned in JCT-VC emails
15:15MrCooper: swick[m]: same really
15:15JEEB: (as I was scrolling through them for the mastering display metadata history)
15:16pq: JEEB, right, it gives a context for the mastering display indeed.
15:17JEEB: ooh, BT.2408 also has "Conversion practices for camera and display RGB colorimetry". and they specifically note > The source and target white points are the same and should be equal to D65
15:18JEEB: > The source and target white point brightness is the same. For scenarios where brightness is different, refer to BT.2446
15:18pq: but we don't deal with any camera image
15:18JEEB: yea, it's just the first time they refer to some case where white point might be different
15:18pq: aaha
15:18swick[m]: MrCooper: maybe I have something really backwards but in the composited case we have a deadline at which we take the latest buffers from clients which are ready submit the GPU work and throw that at KMS. In that case the start of vblank as the deadline is fine. If the GPU work takes longer than the minimum vblank VRR just extends it and all is good.
15:18MrCooper: swick[m]: (I'm assuming the ideal world where mutter's GPU work can perfectly preempt clients' GPU work :)
15:19pq: cameras are complicated anyway, we are happy to deal with display only :-)
15:19JEEB: also lessee what https://www.itu.int/pub/R-REP-BT.2446-1-2021 deals with...
15:19JEEB: oh right this is this doc which has these tone map methods discussed :D
15:19pq: it's also fun that this discussion started flowing roughly the moment I was looking forward to escape for the weekend :-p
15:20JEEB: yea, let's not go there 8)
15:20JEEB: I just started this as I myself got off the dull $dayjob
15:20JEEB: and got to the > multimedia side
15:20JEEB: but yea, enjoy the week-end
15:20pq: thanks! you too
15:21swick[m]: o/
15:22swick[m]: MrCooper: but if we assume direct scanout we have a deadline at which we take the latest buffer from a client which is ready. We commit that to KMS and because the buffer is ready it will use the shortest vblank possible.
15:23MrCooper: swick[m]: with VRR, if a client buffer becomes ready anytime between the start of vblank and the latest possible end of it (minus some buffer for the compositor's work), the compositor can push out a frame immediately if there isn't one pending yet
15:23MrCooper: i.e. the compositor doesn't have to wait for the next start of vblank if there was no ready client buffers at the previous start of vblank
15:24MrCooper: (this isn't implemented in the mutter VRR MR, not for lack of yours truly pushing for it :)
15:26swick[m]: right, so we have a period between start of vblank and end of vblank minus slack in which we monitor if anything gets ready and submit that
15:26swick[m]: but in that case, the deadline is not the start of vblank, is it?
15:27MrCooper: it kind of is, since it would be ideal if the client buffer became ready by then
15:27MrCooper: maybe more like "target" than "deadline"
15:28swick[m]: mh, but the target depends on what the client wants to do, whereas the deadline is just always there
15:28MrCooper: if the client has a specific target, currently it can only wait for that before attaching the buffer to the surface
15:29swick[m]: if it wants to present at a certain time and minimize the latency it has to target somewhere in the middle of vblank
15:29swick[m]: sure, but it could still do that
15:30swick[m]: in the sense that a client could schedule its own work in a way that it will likely finish somewhere in the vblank period
15:33MrCooper: right, but with the current Wayland protocols, the compositor has to assume the target is ASAP, so start of vblank makes sense for communicating to the kernel as deadline/target
15:33swick[m]: for the fence deadline thing? yeah, that makes sense...
15:36MrCooper: yeah
21:44wlb: weston Merge request !1191 opened by Leandro Ribeiro (leandrohrb) Add RUN_MODE_NO_THROTTLE to presentation-shm client https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1191