00:01 karolherbst: okay.. seems like llvm-23 will require us to support CapabilityFMAKHR :')
00:59 karolherbst: Annnnd.. I got a bunch of regressions: https://github.com/llvm/llvm-project/pull/189781
07:42 tzimmermann: arnd. i currently work on the kconfig around CONFIG_SYSFB. if found that many old architectures' defconfigs set CONFIG_FIRMWARE_EDID=y . but FIRMWARE_EDID depends on EFI_GENERIC_STUB || X86, which is not true for many of those defconfigs. if that worth fixing?
07:43 tzimmermann: or rather dropping CONFIG_FIRMWARE_EDID=y from those defconfigs?
07:43 tzimmermann: 'git grep FIRMWARE_EDID' for the files
07:51 arnd: tzimmermann: I took a look at a few of these now and haven't found any indication that ever did anything useful. I'd say fix the defconfig files to drop those lines
07:51 tzimmermann: ok
07:52 arnd: The code used to be guarded by "#if defined(CONFIG_FIRMWARE_EDID) && defined(CONFIG_X86)", when the defconfigs first referenced the symbol, so it was just a nop
07:53 tzimmermann: arnd, can this be one patch? or one per defconfig?
07:54 tzimmermann: or one per arch?
07:55 arnd: I'd suggest one per architecture, you can send the arch/arm/ one to soc@lists.linux.dev with "Suggested-by: Arnd Bergmann <arnd@arndb.de>"
07:55 tzimmermann: ok
07:59 arnd: loongarch uses UEFI and should probably keep it. I expect the powerpc patch to be picked up quickly, while the sh one probably gets ignored. you can still consider funneling the remaining ones through the drm tree, like 9db021e6cbd6 ("sh: defconfig: remove CONFIG_LOGO_SUPERH_*")
08:33 tzimmermann: arnd, yeah. loongarch supports it. i sent out patches for the others
08:34 glehmann: karolherbst: that's fun for adreno
08:48 MrCooper: daniels: FWIW, my understanding is that dithering is only used for transmitting more information with a given bpc, not for selecting lower bpc
08:51 tzimmermann: arnd, lol. sh was the first to respond
12:08 mripard: jani: rodrigovivi: hwentlan__: lumag: robclark: just as a heads up (and in case you missed it by mail) this is happening: https://lore.kernel.org/r/20260331-drm-drm-atomic-update-v2-0-7e8fe6ddcd32@kernel.org
12:12 vsyrjala: can you update the patch subject to say what it is being renamed to?
12:14 vsyrjala: might eliminate one extra step from someone's wtf moment
12:14 mripard: yeah, that was tzimmermann suggestion as well
12:16 vsyrjala: the crtc commit thing vs. drm_atomic_commit might confuse people a bit. but whatever, at least it's less confusing that the current thing
12:22 tzimmermann: arnd, i've been looked at commit e65ca1646311 ("efi: export sysfb_primary_display for EDID"). i think the "|| FIRMWARE_EDID" belongs in the braces. otherwise wouldn't there be two instances of sysfb_primary_display on x86?
12:22 tzimmermann: s/looked/looking/
12:27 tzimmermann: sima, mripard, mlankhorst. comments on https://lore.kernel.org/dri-devel/2026032451-playing-rummage-8fa2@gregkh/ ? if not, i'd like to pick this up into -misc-fixes
12:32 mripard: tzimmermann: ab: me
12:49 arnd: tzimmermann: right, that was a mistake. It is harmless because efi-init.c is only built for arm/arm64/riscv and not x86, but clearly we should either drop the check for x86 or change it as you said
12:49 tzimmermann: arnd, ok. i see. i'll send you a patch
13:10 mlankhorst: Is it possible to rebuild a previous drm-tip using an old integration manifest?
13:17 jani: mlankhorst: manually, yes
13:17 jani: mlankhorst: at some point I considered making the integration manifest a shell script with the git merge commands to do just that, but I never got around to it
13:18 jani: obviously it'll fail at any manual fixup patches
13:19 rodrigovivi: mripard: thanks for the heads up... as jani, no strong opinion on the name and agree it should go directly to drm-next, but up to you
13:25 sima: mlankhorst, reflog on gitlab.fd.o might still have it
13:26 sima: at least I have vague memories that you could pull old versions, but maybe wrong
13:27 sima: tzimmermann, we do the same array_index_nospec for the drm_ioctl array, so r-b: me on applying the same for the compat path
13:27 sima: and yeah cc: stable sounds right too
13:28 mlankhorst: jani: Yeah can just use the old rerere cache for that one. Just wanted to see what happened in 2 historical versions of drm-tip
14:28 MrCooper: looks like I'm not the only one with concerns about the "link bpc" property after all
14:29 daniels: if vsyrjala's complaints are predicated on 'userspace might do dumb shit', then I suggest we don't allow userspace to make any decisions ever
14:29 daniels: s/complaints/concerns/ # sorry
14:41 vsyrjala: i just think userspace doesn't have access to all the information it'd need to make good decisions
14:43 daniels: nor does the kernel ...
14:44 vsyrjala: would the per-outpuit (or crtc) quality weight thing (+ maybe absolute min/max bpc) not cover most things?
14:44 daniels: hence why it wouldn't be 'weston knows better than the kernel', it would be surfacing the exact same overrides that Android TV + Apple TV + Fire TV + Chromecast + etc all specifically went and put overrides in there to allow users to configure it
14:46 daniels: not really, because 'quality' implies a global determination of the relative importance of {resolution, refresh rate, bit depth, colour model, subsampling}
14:49 vsyrjala: i don't think resolution and refresh rate are on the table here. the existing uapi already makes those userspace respnsibilities
14:50 daniels: except userspace can't make good decisions about what it wants, so they probably shouldn't be?
14:51 vsyrjala: i think it's generally the actual user that selects those. but most people probably don't want to be tweaking some control panel color depth knobs to get new displays to light up
14:53 daniels: why would they have to?
14:54 daniels: like I said, every one of those knobs would have to have an 'auto' default that does exactly what happens today (driver does something, hopefully a good thing), and userspace wouldn't screw with that unless specifically configured to do so
14:58 vsyrjala: so you're saying the desired bpc would be sufficient, and userspace should only use it when the user explicitly flips some expert knob?
14:59 vsyrjala: or could even be a 'min bpc' if failing the commit because of it is fine
15:06 daniels: well, link bpc would allow, effectively, a min bpc implementation
15:06 daniels: (and yes expert knob! doing it blindly would be idiotic)
15:07 MrCooper: not without multiple non-TEST_ONLY commits (or some kind of new feedback mechanism)?
15:09 daniels: correct, but that’s where we are
15:10 daniels: realistically, adjusting those settings involves trying it and seeing if your TV actually displays anything anyway
15:10 vsyrjala: what would userspace adjust if the 'link bpc' looks not right?
15:11 vsyrjala: just reduce 'max bpc' on other outputs until things look better?
15:12 vsyrjala: and doing that essentially randmdomly since the user doesn't know where the actual bottleneck is
15:12 zamundaaa[m]: Without further feedback about why the test failed, compositors would likely assume that the connector bandwidth is the problem, and downgrade refresh rate, resolution or chroma subsampling
15:12 daniels: I have one hermetic product for which the desired outcome is declaring failure and not proceeding
15:14 daniels: for others, as zamundaaa[m] says, it would be to give up on RGB+444+low-bpc, to drop down to YUV+420+higher-bpc
15:15 lumag: mripard, mlankhorst, tzimmermann: would you please ack merging of http://lore.kernel.org/r/20260318-dsi-dsc-slice-per-pkt-v2-1-0a1b316f8250@pm.me through msm-next?
15:28 vsyrjala: zamundaaa[m]: in this case the test wouldn't fail. you just get low link bpc back
15:30 vsyrjala: i just don't see how this link bpc can help the user resolve this in a way that they get the high resolutuon+high bpc mode they want
15:31 zamundaaa[m]: vsyrjala: right, but the compositor knows it didn't achieve what it wanted
15:31 zamundaaa[m]: Having a property that actually fails the commit when it can't be achieved might be more useful there, in combination with the proposed additional feedback on failure
15:32 vsyrjala: right. so i think a 'min bpc' could sort of solve it. set that on the imporant connector, and the kernel is still free to degrade the other connectors harder