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
Leopold has quit [Ping timeout: 480 seconds]
shsharma__ has joined #wayland
Ampera has quit [Quit: Don't look at my quit message, steve30 has a better one anyways.]
Ampera has joined #wayland
shsharma_ has quit [Ping timeout: 480 seconds]
kasper93_ has joined #wayland
kasper93 is now known as Guest7990
kasper93_ is now known as kasper93
Guest7990 has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
soreau has joined #wayland
julio7359 has joined #wayland
kasper93 has quit [Read error: Connection reset by peer]
<kennylevinsen>
pq: It doesn't help that vsync is at times misused to refer to synchronization with vblank :)
<emersion>
i'm not sure that's a mis-use tbh
<emersion>
you can see it the other way: vsync is misused to refer to the vertical sync pulse
<pq>
vsync *is* the vertical sync pulse
<pq>
but yeah, I guess UIs use the same word for "do not tear and do not drop frames" or something
nerdopolis has joined #wayland
<pq>
that's actually the rule rather than exception
<pq>
but when the talk context is video timings, sync pulse prevails
<pq>
the sync pulse existed first
floof58 is now known as Guest8038
floof58 has joined #wayland
kts has quit [Quit: Konversation terminated!]
<emersion>
hm
Guest8038 has quit [Ping timeout: 480 seconds]
<vsyrjala>
with vga/etc. actual vsync status bit is all you got, so it was also used to do the rendering vs. scanout synchronization
<vsyrjala>
that is presumably the source of the overlapping terminology
Fxzxmic has quit [Quit: Konversation exit!]
<swick[m]>
pq: nope, it's as vague about the mastering display color volume as all the other documents
<pq>
pfft
<JEEB>
99% of that is like display p3 and 1000 to 4000 nits I think?
<JEEB>
"calibrated to this gamut and eotf with clip at xyz nits"
<pq>
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.
<JEEB>
i think technically yes, but no-one thought of mentioning it explicitly since in the vast majority of cases it happens to match
<JEEB>
since white point is part of primaries
<JEEB>
i would prefer if that was written somewhere that the relevant folks thought of it
<JEEB>
or oooh we totally didn't think of it, let's see
<pq>
the whole question started from "why does ST 2086 metadata carry also white point"
<JEEB>
it's part of the primaries' definition so carrying it is just the default you do, I think?
<JEEB>
but yea will see if I can find anything historical
<pq>
sure, I'd do that too
<pq>
but if you carry it, it can differ from the white point of the encoding space, so what do I do then
<pq>
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.
<pq>
which is a few steps away from using those parameters to guide gamut and tone mapping
realivanjx2 has joined #wayland
realivanjx2 has quit [Read error: Connection reset by peer]
junaid has quit [Remote host closed the connection]
<heeen>
can you resolve an id to a wl_resource
<kennylevinsen>
heeen: client or server?
<heeen>
server
<kennylevinsen>
wl_client_get_object does that
<heeen>
are resource ids unique in the server?
<heeen>
I forgot if they are client supplied or server
<kennylevinsen>
supplied by client and scoped as such
<kennylevinsen>
hence it being tied to struct wl_client
<heeen>
so an id also needs the client this resource belongs to to identify the resource?
<kennylevinsen>
yes, an IDs only make sense in the context of the client that made it
<heeen>
is there an id within the server that uniquely identifies resources across clients? apart from the memory address of the wl_resource
<kennylevinsen>
no
<heeen>
do clients have an id
<kennylevinsen>
you also normally do not resolve resources from ids yourself, as the server protocol implementation did it for you in its callbacks
<kennylevinsen>
clients have a wl_client struct
jmdaemon has joined #wayland
<heeen>
I am trying to write a DBus API that references shell surfaces and other resources
<heeen>
so my naive idea was to just use resource ids, but I forgot those were client supplied and not unique globally
<heeen>
so I suppose I need to create my own key, like an incrementing Id or something
<kennylevinsen>
look at xdg-foreign-unstable
<heeen>
thanks
<kennylevinsen>
the way it gives surfaces a token is probably similar to what you will need
<kennylevinsen>
(maybe the same token, or at least the way of storing it can be reused in the compositor you are implementing it in)
<heeen>
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
<kennylevinsen>
you could start by publishing the xdg-toplegel app IDs
<kennylevinsen>
the task switcher would likely want to know those anyway
<kennylevinsen>
but for identifying every individual toplevel you'd likely want a randomized string token that the compositor generates and stores with the toplevel
<heeen>
we're not implementing xdg anything I think
<heeen>
unless qt does that under the hood
<heeen>
we have our own shell extension, own shell surfaces
<kennylevinsen>
well potato tomato, for whatever your toplevel-ish shell surface is you would store a random string token for later reference
kts has joined #wayland
<swick[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.
<swick[m]>
that's not really the case in a lot of situations though, is it?
<swick[m]>
playing a video at n 25fps, games running at n30fps, etc
jmdaemon has quit [Ping timeout: 480 seconds]
<MrCooper>
right now there's no mechanism for clients to communicate that to the compositor, so it has to assume the target is ASAP
<swick[m]>
ahh, I see where you're coming from
<swick[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
<JEEB>
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"
<swick[m]>
it only works if we commit buffers which are potentially not ready
<MrCooper>
swick[m]: why? buffers may become ready only after start of vblank
<MrCooper>
then the compositor can push out the next frame ASAP
<pq>
JEEB, yeah, BT.2100 has that definition. What are we talking about?
<MrCooper>
which results in refresh rate somewhere in the VRR range
<swick[m]>
MrCooper: mh, what exactly are we talking about? direct scanout or composited VRR?
<JEEB>
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
<MrCooper>
swick[m]: same really
<JEEB>
(as I was scrolling through them for the mastering display metadata history)
<pq>
JEEB, right, it gives a context for the mastering display indeed.
<JEEB>
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
<JEEB>
> The source and target white point brightness is the same. For scenarios where brightness is different, refer to BT.2446
<pq>
but we don't deal with any camera image
<JEEB>
yea, it's just the first time they refer to some case where white point might be different
<pq>
aaha
<swick[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.
<MrCooper>
swick[m]: (I'm assuming the ideal world where mutter's GPU work can perfectly preempt clients' GPU work :)
<pq>
cameras are complicated anyway, we are happy to deal with display only :-)
<JEEB>
oh right this is this doc which has these tone map methods discussed :D
<pq>
it's also fun that this discussion started flowing roughly the moment I was looking forward to escape for the weekend :-p
<JEEB>
yea, let's not go there 8)
<JEEB>
I just started this as I myself got off the dull $dayjob
<JEEB>
and got to the > multimedia side
<JEEB>
but yea, enjoy the week-end
<pq>
thanks! you too
<swick[m]>
o/
<swick[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.
<MrCooper>
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
<MrCooper>
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
<MrCooper>
(this isn't implemented in the mutter VRR MR, not for lack of yours truly pushing for it :)
<swick[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
<swick[m]>
but in that case, the deadline is not the start of vblank, is it?
<MrCooper>
it kind of is, since it would be ideal if the client buffer became ready by then
<MrCooper>
maybe more like "target" than "deadline"
<swick[m]>
mh, but the target depends on what the client wants to do, whereas the deadline is just always there
<MrCooper>
if the client has a specific target, currently it can only wait for that before attaching the buffer to the surface
<swick[m]>
if it wants to present at a certain time and minimize the latency it has to target somewhere in the middle of vblank
<swick[m]>
sure, but it could still do that
<swick[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
<MrCooper>
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
<swick[m]>
for the fence deadline thing? yeah, that makes sense...
<MrCooper>
yeah
Company has joined #wayland
jmdaemon has joined #wayland
fmuellner has joined #wayland
DPA has quit [Ping timeout: 480 seconds]
floof58 has quit [Quit: floof58]
floof58 has joined #wayland
rv1sr has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
kts has quit [Quit: Konversation terminated!]
DPA has joined #wayland
kasper93 has joined #wayland
___nick___ has joined #wayland
julio7359 has joined #wayland
soreau has quit [Ping timeout: 480 seconds]
soreau has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
soreau has quit [Ping timeout: 480 seconds]
DPA has quit [Ping timeout: 480 seconds]
soreau has joined #wayland
dcz has joined #wayland
DPA has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
vyivel has quit [Remote host closed the connection]
vyivel has joined #wayland
jmdaemon has joined #wayland
molinari has quit [Ping timeout: 480 seconds]
mvlad has quit [Quit: Leaving]
rv1sr has joined #wayland
shsharma__ is now known as shashanks
Szadek has quit [Quit: WeeChat 3.8]
Szadek has joined #wayland
Szadek has quit [Quit: WeeChat 3.8]
julio7359 has quit [Remote host closed the connection]