08:20 biju: mripard: Just a question when will the drm-misc-next point to linux-next? Currently only patches in drm-misc-next-fixes appears in next
08:30 mripard: biju: when rc1 is released
08:32 biju: mripard: Thanks
08:45 tzimmermann: PSA: With the merge window comming to an end, drm-misc-next-fixes is now closed again. After -rc1 has been released, relevant fixes go into drm-misc-fixes. Patches in -fixes branches should be small and have a Fixes tag. New features always go into drm-misc-next.
12:10 CounterPillow: lumag: if you have the time, a quick "this is fine" vs "please no" on color format v13 would be appreciated so I can roll up any requested changes into v14. Specifically want to know if my bridge connector based thing for "is this hdmi? if so, use hdmi format" is finally satisfactory:
12:10 CounterPillow: https://lore.kernel.org/dri-devel/20260413-color-format-v13-4-ab37d4dfba48@collabora.com/
12:10 CounterPillow: https://lore.kernel.org/dri-devel/20260413-color-format-v13-5-ab37d4dfba48@collabora.com/
12:10 CounterPillow: https://lore.kernel.org/dri-devel/20260413-color-format-v13-6-ab37d4dfba48@collabora.com/
12:32 tomba: tzimmermann: We've got a fix in drm-misc-next, 3e9a1da270ddff449b1ad9eadc958f43bc204bd2. But that one is a fix to a commit that has already gone to linus' tree. Can I cherry pick and push that fix to drm-misc-fixes, even if that results in a duplicate commit?
12:35 tzimmermann: tomba, of course. the fix also looks important. 'dim cherry-pick' will automatically mention the original git hash in the commit message
12:35 tomba: tzimmermann: thanks. I'll do that now.
12:41 tomba: tzimmermann: or not. drm-misc-fixes doesn't contain the commit that needs fixing, so I think drm-misc-fixes hasn't been synced to the latest yet. is that done when the merge window closes?
12:41 tzimmermann: should not be a problem, i think.
12:41 tzimmermann: mripard ^
12:42 mripard: tzimmermann: on it
12:42 tzimmermann: great. thanks, mripard
12:44 mripard: tzimmermann: tomba: should be ok now
12:46 tzimmermann: tomba, i only see commit 3bce3fdd1ff2 in drm-next, but not in an upstream
12:46 tzimmermann: branch
12:47 tomba: tzimmermann: hmm. "git branch -r --contains 3bce3fdd1ff2" says it's in linus/master for me.
12:48 tzimmermann: tomba. ok, i see. can you add the fix to drm-misc-fixes now?
12:49 tomba: tzimmermann: no... mripard: I still don't see 3bce3fdd1ff2 in drm-misc-fixes
12:50 tzimmermann: tomba. because the bug isn't in drm-fixes yet.
12:50 tzimmermann: tomba. let me reopen drm-misc-next-fixes for you. the bug should be there and you can put the fix on top
12:50 tomba: tzimmermann: oh. ah... so many branches... =)
12:51 tzimmermann: because we need a reason to justify 3 maintainers for drm-misc :P
12:52 mripard: more like it's unacceptable for most to wait a month without applying patches :)
12:52 tzimmermann: tomba, i've reopened drm-misc-next-fixes for you. you can put the fix into this branch
12:53 tzimmermann: ping me when you're done and i'll send out the PR
13:01 tomba: tzimmermann: I have pushed the branch
13:07 MrCooper: huh, no conflicts merging drm-next-2026-04-22 into linux-7.0.y, too easy :)
13:09 tzimmermann: tomba, great. PR is out
13:09 tomba: tzimmermann: thanks!
13:23 CounterPillow: Quick straw poll: if I add KMS properties to set a fixed target frame rate for VRR, should they be A) on the connector, B) on the CRTC?
13:25 CounterPillow: What speaks for CRTC is that VRR_ENABLED is on the CRTC, and the CRTC is fundamentally what's involved in the video output signalling new frames. What speaks for the connector is that the connector is what vrr_capable is on, and it will need to validate the values of those properties during atomic check against the connector display info EDID.
13:26 MrCooper: B) makes more sense to me; different connectors driven by the same CRTC couldn't have different values, could they?
13:26 CounterPillow: Hmmm, that's an excellent point
13:27 MrCooper: did you read the previous discussion about this, e.g. at last year's display hackfest? E.g. it shouldn't be a single value but a min/max range
13:28 CounterPillow: I didn't :) Currently in my implementation it's two values, a numerator and denominator.
13:28 CounterPillow: This is so we can support historical mistakes like 24/1.001 with infinite* precision
13:30 CounterPillow: If you have a link to the prior discussion I'd be interested. I currently don't know what the benefit of a min and max target is
13:32 CounterPillow: What I do think would be beneficial though is if the target rate is allowed to achieved by hitting an integer multiple of the target rate and then simply framedoubling in-kernel, if it is within source and sink hardware limits. That's because e.g. quite a few computer monitors don't go as low as 24Hz but they will happily do 48Hz
13:32 CounterPillow: But also I guess that's just reinventing FVA with none of the signalling
13:35 MrCooper: see https://hwentland.github.io/work/2025hackfest-notes.html#vrr-for-desktop-use-cases , doesn't have much detail though
13:35 MrCooper: the general idea is that a range allows the compositor to handle low frame-rate compensation itself
13:38 CounterPillow: Hm, not entirely sure how it'd do that. To compensate for a frame rate below the hardware supported minimum, you don't really want a continuous range from a minimum point to a maximum point, but discrete target rates you'd be fine with because they're integer multiples
13:39 zamundaaa[m]: The range is required to allow for example games to change in refresh rate on the next frame
13:39 CounterPillow: Yeah, but they can already do this with the current VRR mechanism by not setting a target rate
13:39 zamundaaa[m]: The problem was that we can only change the range on the next frame, not on the current one
13:40 zamundaaa[m]: Not setting a target means you allow any and all refresh rates, which causes other problems
13:40 zamundaaa[m]: Like, you can't update the cursor in the LFC frames
13:40 zamundaaa[m]: And allowing the refresh rate to change an arbitrarily large amount causes flickering on some displays
13:41 CounterPillow: Yeah, that's what mdelta/cinemavrr in HDMI parlance is supposed to address. I can see a min/max limit make sense for the game use case now, where we're just trying to tell the VRR logic not to go too crazy
13:52 CounterPillow: If there is a min/max target frame rate, then having that property as part of the connector again may actually make some sense, since a CRTC driving multiple connectors can satisfy both connectors if both of them intersect in their min/max range.
13:52 CounterPillow: but that seems like an extremely niche use case
13:53 CounterPillow: especially since the compositor could figure out the overlap on its side in such a situation
13:57 MrCooper: my argument for B) above applies similarly to a range as to a single value — the effective refresh rate is determined by the CRTC, so different ranges per-connector are meaningless
14:16 vsyrjala: imo the only kinds of things that make sense in a new vrr uapi are either frame times (which given small enough units should have sufficient precision), or possibly a fractional vtotal values (as that's what the hardware wants anyway). refresh rate should not be used imo (just as it's not used in the existing uapi)
14:17 CounterPillow: then you have to convert from vtotal value to frame rate during the check phase to check it against the EDIDs limits, which are given in frame rate
14:18 vsyrjala: that's fine. we do that anyway already
14:18 CounterPillow: would also mean that userspace has to be aware of any hijinks that may be going on on the kernel side, i.e. adjusted_mode
14:18 vsyrjala: modern drivers shouldn't do weird things with that
14:19 vsyrjala: and all uapi values are all relative to the uapi mode anyway
14:19 vsyrjala: frame time is also just the inverse of the frame rate, but with more sensible units
14:20 CounterPillow: The other problem is that once we then get to QMS, the fractional representation of rates lets us precisely match it to a QMS TFR byte, whereas we need epsilon matching for a frame time specified in us or whatever
14:25 daniels: (I also can't see how it could be anything other than CRTC, given that CRTC is the thing which actually generates the timing. the fact the connector has to validate against CRTC properties is fine, given that it already has to validate e.g. mode.)
14:29 vsyrjala: iirc what i remeber about some hdmi stuff is that it just wanted vtotals. and the adaptive sync sdp is completely idiotic with its hardcoded 1.0 vs. 1.001 stuff and nothing else
14:32 CounterPillow: the HDMI EDID extension does operate in frame rates. The packets themselves are a mixture of frame rates to specify the base rate, and actual vtotal value iirc, but I'd need to double-check
14:34 daniels: yeah, you get an explicit list of m/n pairs which are allowed, each of which have essentially a specific mode id
14:34 vsyrjala: this is about enumerating the modes from the sink?
14:34 daniels: so if we were using refresh duration (definitely better than rate fwiw), we'd have to have a table mapping specific values to m/n pairs
14:36 daniels: vsyrjala: that and about passing the target frame rate over to the sink
14:38 vsyrjala: which spec are we talking about here?
14:38 CounterPillow: The One That Shall Not Be Named But Starts With H And Ends With 2.1
14:39 CounterPillow: And I think QMS is HDMI 2.1a
14:41 vsyrjala: i think i have some old copy which only had something messy to say about vtotals, but no hdmi ext block or antyhing like that iirc
14:41 vsyrjala: don't really want to look at it until it's all cleared
15:03 MrCooper: CounterPillow: also see https://patchwork.freedesktop.org/patch/674429/ and the discussion there
20:45 anholt: valentine: you don't have anyone working on a vkcts uprev, do you? (looking at doing it, so we can pull in the memory use fixes and hopefully get boards completing faster again)
20:56 valentine: anholt: I don't think anyone's working on it, so that'd be great
21:35 karolherbst: robclark: I'm seeing that ir3 uses `!ffma` in rules, is there any special reason for this?
21:38 robclark: karolherbst: if you mean the trig rules, dfe432d829257dd01070ae1dcd4b663a0e96641f
21:38 karolherbst: ohh association right...
21:38 karolherbst: okay, I'm working on untangling that mess 🙃
21:39 robclark: \o/
21:41 karolherbst: I'll leave this as "fmad" for now, because I don't want to make too many changes at once, but I'm working to add fmad and ffma_weak (that's like GLSL ffma) and make sure ffma is always fused (like CL ffma or SPV_KHR_fma). So ir3 would just see "fmad" and all the oddities would go away
21:43 karolherbst: ohh yeah and ir3_nir_opt_algebraic_late can go away then 🙃