00:01karolherbst: okay.. seems like llvm-23 will require us to support CapabilityFMAKHR :')
00:59karolherbst: Annnnd.. I got a bunch of regressions: https://github.com/llvm/llvm-project/pull/189781 07:42tzimmermann: 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:43tzimmermann: or rather dropping CONFIG_FIRMWARE_EDID=y from those defconfigs?
07:43tzimmermann: 'git grep FIRMWARE_EDID' for the files
07:51arnd: 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:51tzimmermann: ok
07:52arnd: 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:53tzimmermann: arnd, can this be one patch? or one per defconfig?
07:54tzimmermann: or one per arch?
07:55arnd: 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:55tzimmermann: ok
07:59arnd: 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:33tzimmermann: arnd, yeah. loongarch supports it. i sent out patches for the others
08:34glehmann: karolherbst: that's fun for adreno
08:48MrCooper: daniels: FWIW, my understanding is that dithering is only used for transmitting more information with a given bpc, not for selecting lower bpc
08:51tzimmermann: arnd, lol. sh was the first to respond
12:08mripard: 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:12vsyrjala: can you update the patch subject to say what it is being renamed to?
12:14vsyrjala: might eliminate one extra step from someone's wtf moment
12:14mripard: yeah, that was tzimmermann suggestion as well
12:16vsyrjala: 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:22tzimmermann: 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:22tzimmermann: s/looked/looking/
12:27tzimmermann: 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:32mripard: tzimmermann: ab: me