07:28 jani: mlankhorst: could you do that one more drm-misc-next pull req, please? airlied was okay with that
07:42 airlied: mlankhorst: pushed out new memcg code to the same branch
08:07 mlankhorst: airlied: thanks, will rebase
08:11 mlankhorst: jani: I will in a bit. I'm currently looking for reviewers for the display side of GGTT rework first.
08:13 jani: mlankhorst: *jedi hand motion* I am not the reviewer you are looking for
08:13 jani: mlankhorst: I mean seriously that area is not my strong suit
08:13 jani: e
08:14 mlankhorst: It's nobody's on display side since it's mostly xe, just needs an ack
08:14 mlankhorst: I have the same problem on the xe side with the series. :)
10:40 MrCooper: tzimmermann: re your gamma LUT helper series, using gamma 2.2 for the default ramps would most certainly be wrong, the gamma 2.2 conversion happens later in the display pipeline, usually in the monitor
11:01 pq: MrCooper, that depends... what's it used for?
11:02 pq: https://lore.kernel.org/dri-devel/20250509083911.39018-1-tzimmermann@suse.de/ ?
11:07 pq: ok, the idea in the explanation is not quite right.
11:22 tzimmermann: MrCooper. ok, thnaks for the note. the monitor uses 2.2. so the helpers would use the inverse, right?
11:24 tzimmermann: but as the cover letter says, it's not implemented anyway
11:26 pq: tzimmermann, not really. All software currently assumes that KMS won't... well, current software assumes that drivers behave like they always have.
11:26 tzimmermann: then we better not implement this idea
11:27 tzimmermann: the current code uses a linear ramp, which everything seem sto be ok with
11:27 pq: yes, it's no-op (I assume also hardware-wise?) so that's good.
11:28 pq: tzimmermann, a monitor applies the power-2.2 curve on emitting the light. Userspace assumes that that is what happens. Making the ramp non-identity to break it.
11:28 pq: *would break it
11:29 tzimmermann: pq, but userspace is also expected to program the gamma ramp
11:29 pq: sure - but then it's in addition to what the monitor already does.
11:30 tzimmermann: the default would *only* ever be used if userspace does not set the gamma ramp
11:30 pq: does fbcon reset the ramp, btw?
11:31 tzimmermann: the helpers do not apply a gamma ramp in addition to what userspace sets
11:31 pq: fbcon really should reset it
11:31 tzimmermann: don't know
11:31 tzimmermann: but if, i've never seen code that computes a sophisticated gamma ramp
11:31 pq: That's how KMS hand-off works, one better re-program *everything* when gaining DRM master.
11:32 pq: reset it to identity, I mean
11:32 tzimmermann: that's how these helpers currently work (and also the drivers from which they come). so things should be fine
11:33 pq: Anyway, the fact that pixel values go through power-2.2 before emitted as light intensity is a good thing. If that curve didn't exist, we'd have much poorer image quality.
11:33 pq: cool
11:34 pq: I'm just used to running fbcon in HDR mode, because fbcon does not reset all KMS properties. And I think the ramps used to be a similar problem, too. :-)
11:35 pq: ...actually that's fbdev, sorry. That monitor doesn't have a console.
12:20 MrCooper: pq tzimmermann: pretty sure fbcon still doesn't restore its gamma ramp when switching to one of its VTs
13:02 rburton: good day, all. quick one: is spirv-tools a build-time only dependency for mesa, or is a part of it needed at runtime?
13:09 DragoonAethis: rburton: it's a runtime dependency for some debugging tools in Mesa (assembly dumps)
13:09 rburton: sounds like something i can not install by default, thanks
20:41 rburton: is it possible to build just the mesa drivers and none of the app-facing, and then separately the drivers and none of the libraries?
23:24 mdnavare_: How can I use the drm dp aux sysfs to read any DPCD register on a DRM device?
23:57 airlied: mdnavare_: I think you should use /dev/drm_dp_aux0