06:30 wens: are drm/exynos patches merged through drm-misc or a separate tree? I see two entries in the MAINTAINERS file.
06:37 airlied: usually the exynos tree
06:46 wens: I see, the double entry was a bit confusing
07:26 MrCooper: kusma: your "Open Source and AI" blog post expresses my thoughts on the subject better than I could have myself, thanks!
07:43 pq: zmike, thank you very much for fixing the llvmpipe LastFragData!
08:54 mripard: airlied: sima: mlankhorst: tzimmermann: any opinion on https://lore.kernel.org/r/20260326-drm-drm-atomic-update-v1-0-2f7af5f4ad02@kernel.org ?
08:57 tzimmermann: mripard, well, ok
08:57 tzimmermann: mripard, the canonical name would be transaction
08:58 mripard: that's what sima suggested
08:58 tzimmermann: although that might over-sell it a bit
08:58 mripard: but the todo was "commit" :)
08:58 mripard: so I took the middle road ignored both equally :p
08:58 mripard: I'm ok with transaction too
08:58 tzimmermann: :D
08:59 sima: same, either is a massive improvement over the current situation
08:59 tzimmermann: the thing with transaction is that is doesn't really say what transaction. would that be clear from the context of drm?
08:59 sima: also historically drm_atomic_state was just a state and used clever tricks to make it a commit
09:00 sima: turned out the tricks where too clever and explicit old/new states so much better design
09:00 sima:did a little mistake
09:00 sima: tzimmermann, hm yeah I think commit is a bit more established within the context of kms than transaction
09:00 sima: either way, a-b: me
09:01 tzimmermann: there is an atomic_update callback already. having drm_atomic_update seems misleading
09:01 mripard: I'm fine with commit as well, but is there a concern with drm_crtc_commit?
09:01 tzimmermann: how about "struct drm_state_update" ?
09:02 tzimmermann: mripard, its not just 'crtc'
09:02 sima: mripard, that one is also about tracking an atomic commit, so I think that's actually bonus for consistency
09:03 sima: I've added drm_crtc_commit so that a generic nonblocking helper implementation is possible
09:03 mripard: ok, so we all agree to use drm_atomic_commit then?
09:03 tzimmermann: i can live with that
09:03 mripard: awesome
09:03 sima: not entirely awake, maybe collect a few more acks from big driver kms people
09:04 tzimmermann: a-b: me
09:04 sima: but yeah, sounds like the most fitting
09:04 sima: but I'm a-b: me on any of transaction/commit/update really, all better than the current one
09:04 mripard: I know pinchartl had opinions too :)
09:04 mripard: and I'll send a new version with drm_atomic_commit anyway, we can gather a-b there
09:04 sima: for merging probably best if airlied pushes it onto drm-next after -rc6/7 when all the big -next pr have landed
09:05 sima: that's probably the least painful point
09:05 sima: mripard, aye
09:05 mripard: that was my next question
09:05 mripard: sounds good to me
09:05 mripard: I'll send it today
09:05 mripard: thanks :)
09:05 sima: mripard, yeah don't have a better idea, but also good excuse to get acks from the other subtrees (msm, intel-display, amd) so they're at the ready for the asap backmerge
09:28 pinchartl: mripard: apparently I have opinions on everything :-)
09:29 pinchartl: I think I have a slight preference for commit, as it matches the UAPI naming
09:29 pinchartl: but I won't bikeshed much
09:36 tzimmermann: PSA: With -rc6 tagged, drm-misc-next-fixes is now open. Features still go into drm-misc-next. Fixes for v6.19 or stable go into drm-misc-fixes. Fixes for v7.0 go into drm-misc-next-fixes. Patches in -fixes branches should be small and have a Fixes tag.
12:12 zmike: pq: 🤝
13:06 MrCooper: pq: I'm thinking more and more that the "max bpc" property really isn't suitable for the stated use case (RGB vs YCbCr), instead what's really needed there is a property to explicitly control the bpc?
13:08 MrCooper: no need to guess what the intent was for setting "max bpc" to a given value then
13:13 pq: MrCooper, I've been ignoring 'max bpc' because it's completely unrelated.
13:14 MrCooper: it's currently required for the stated use case
13:14 daniels: well, it's part of it
13:14 pq: it is programmed IIRC, but not required
13:14 MrCooper: there's no other way to control bpc
13:14 pq: there is no need to control bpc for this use case
13:15 daniels: the usecase isn't specifically to log a warning - the usecase is to enable control UI to be able to have a feedback loop and take better decisions on resolution / refresh rate / colour model
13:15 pq: daniels, weston cannot do anything but log, though.
13:15 MrCooper: and it logs only if the user sets a value for "max bpc"
13:16 daniels: i.e. if you can hit 4k60 with no subsampling only by cutting down to 6bpc, the user (or media playback control) may decide that it would be better as a matter of policy to try 4k60+YUV422 to see if it will look less terrible, and if it still doesn't get any joy out of that, to pull down to 1080p
13:17 daniels: there's no universally-correct answer, hence why the kernel can't 'dtrt' - but if userspace has no idea what the kernel is even doing, it's impossible for userspace to tell the kernel what the right thing would actually be
13:17 pq: MrCooper, if you read my comments in the Weston MR, I have asked to not use max_bpc for that but add a new "desired bpc" settings.
13:18 MrCooper: then we agree on that; trying to (ab)use "max bpc" for something it's not intended for is something that bothers me about this
13:18 pq: yes!
13:18 daniels:shrugs
13:19 MrCooper: that would also largely side-step the issues we've been discussing — either the kernel can make the requested bpc work, or the atomic commit fails
13:19 daniels: I agree that max bpc is not what we'd ideally have as the sole control mechanism; otoh it's hard to say that we shouldn't have a feedback mechanism for the control mechanism that we do actually have upstream, and that it can only come with a control mechanism which can express quite a few different orthogonal things
13:22 MrCooper: the thing that bothers me the most is that the weston MR implies the "link bpc" value is expected to match the "max bpc" one
13:22 pq: daniels, there is nothing to argue anymore. The Weston MR just needs the changes I suggested ages ago.