07:48 <javierm> arnd, geertu: thanks a lot for your feedback on the FB_CORE series. I'm much more happy with the end result now

07:49 <arnd> javierm: I still want to check what the 'menuconfig menus look like with CONFIG_FB disabled, I suspect the fbdev submenu is messed up now but I have not looked at it

07:50 <arnd> javierm: the way the submenus work is really odd, I think you need to ensure that every option below a 'menuconfig' entry has a dependency on the Kconfig option name

07:54 <arnd> for some reason, drivers/video/fbdev/Kconfig has individual 'depends on FB' in every single line, rather than the usual 'if FB // endif' block around them.

07:54 <javierm> arnd: I haven't used menuconfig in more than a decade (I used to do that when it was feasible to actually configure stuff way), let me take a look

07:54 <javierm> *that way

07:54 <arnd> javierm: I think what you need to do to get it right is to move every option that no longer depends on FB ahead of the 'menuconfig FB' block

07:56 <arnd> it would be nice to also clean up the Kconfig file by changing the individual FB dependencies into a large block if/endif, but that is only cosmetic and doesn't cause a functional difference

08:00 <javierm> arnd: I've just checked with `make menuconfig`. The only user visible symbol that depends on FB_CORE is FB_DEVICE now after your suggested changes

08:01 <javierm> and I can still toggle that one from the menuconfig ncurses UI after FB is disabled

08:01 <javierm> arnd: so I think that removing the individual depends on FB and moving all that in an if/endif block would be a nice cleanup but IMO can be done as a follow-up

08:02 <arnd> javierm: what happens if you turn on FB in menuconfig now? If FB_DEVICE comes after FB but does not depend on it, I think all the drivers show up in the same level as FB rather than in the submenu

08:03 <arnd> Maybe you can move FB_DEVICE all the way to the end of the Kconfig file

08:04 <arnd> In theory we could have separate toggles for FB_DEVICE (device nodes for old style fbdev drivers) and DRM_FB_DEVICE (/dev/fb* nodes for drm-style drivers), that would fix the menuconfig listing but I'm not sure if that ends up more confusing to the user

08:06 <javierm> arnd: https://imgur.com/qFqSOYX

08:07 <arnd> right, that's broken

08:07 <javierm> even when it says "*** Frame buffer hardware drivers ***" before the drivers?

08:07 <javierm> it should be a new level under CONFIG_FB ?

08:08 <javierm> arnd: I struggle every time that I need to make some non-trivial change to a Kconfig :)

08:10 <arnd> javierm: what I mean is that you shouldn't inadvertently change the hierarchy. Before your patch, you have a "Graphics support" menu, inside of that there is a "Frame buffer Devices" menu, and inside of that there is a "Support for frame buffer devices", which contains all the fbdev driver options

08:10 <arnd> it looks like the "Support for frame buffer devices" is now an empty submenu, with everything from it moved up one level

08:15 <arnd> The current structure is of course a mess already, and it would be nice to clean that up as a side-effect, but anything that changes should be intentional and described in the changelog text

08:16 <arnd> I see that CONFIG_MMP_DISP is the only thing in the second menu that is not inside of the third menu, that is probably a bug, and it's only visible if CPU_PXA910 or CPU_MMP2 are enabled

08:17 <arnd> oh, or COMPILE_TEST

08:17 <javierm> arnd: I see what you mean now

08:18 <javierm> arnd: we need a if FB and endif # FB and put all the fbdev drivers inside that

08:19 <arnd> Maybe we can move all the core options including FB_DEVICE into a new drivers/video/fbdev/core/Kconfig file and include that one before drivers/video/fbdev/Kconfig

08:20 <arnd> the "if FB" is just syntactical sure, that part should not be required, though you could do that as a first step in order to make it clearer what is going on

08:20 <arnd> s/sure/sugar/

08:21 <javierm> arnd: so you don't want that in the end result then? And just do it as a preparatory step to move the core into drivers/video/fbdev/core/Kconfig ?

08:21 <javierm> I was thinking about doing both

08:22 <javierm> that is, move all the core Kconfig options to drivers/video/fbdev/core/Kconfig and put all the drivers inside an if/endif block

08:22 <arnd> javierm: I don't care much about the if/endif block, it seems like a nice cleanup but it might be a bit of a distraction since it's technically unrelated to the other changes

08:24 <arnd> the way that "make menuconfig" parses this is to put everything after a "menuconfig FB" that depends on FB into the submenu, and everything starting from the first option that does not depend on it after the submenu on the same level.

08:24 <arnd> It does not care about file hiearchy or whether the dependency comes from an if/endif block or a 'depends on' line

08:27 <javierm> arnd: got it. Then a workaround until we do the proper core / fbdev Kconfig symbol split in a new file is to just move `config FB` to the end of the core options and just before the start of the fbdev drivers

08:28 <arnd> right, that should work, we just need to decide whether we want the FB_DEVICE option before or after the FB menu

08:29 <geertu> I think most logical is after the FB menu

08:30 <arnd> javierm: I still wouldn't mind just leaving the FB_DEVICE option inside of the CONFIG_FB submenu as I suggested earlier. I think your objection was that this would make it harder to use /dev/fb* with DRM while leaving fbdev drivers out of the kernel, but I don't think that's a huge issue

08:30 <arnd> if anyone wants this configuration, they are still able to enable CONFIG_FB and CONFIG_FB_DEVICE but leave the individual drivers turned off

08:31 <LeSpocky> hello

08:31 <geertu> arnd: the drm people do not want to enable CONFIG_FB for that

08:32 <LeSpocky> after upgrading kernel from v6.3 to v6.4 at91 sama5d2-som1-ek1 board can not access the SPI-NOR on the SoM anymore, kernel log says this:

08:32 <LeSpocky> [ 2.159196] spi-nor spi1.0: unrecognized JEDEC id bytes: ff ff ff ff ff ff

08:32 <LeSpocky> is that a known issue?

08:34 <javierm> arnd: yeah, that's an uncommon case so I wouldn't mind either. i.e: needing /dev/fb* but only with DRM fbdev emulation will require to explicitly disable all the fbdev drivers

08:34 <javierm> arnd: that would solve the broken menuconfig too right ?

08:35 <arnd> geertu: who in particular? I though it was just javierm that mentioned this, while the idea for splitting out FB_DEVICE was that "modern" systems should really disable both FB and FB_DEVICE

08:36 <arnd> javierm: I think to solve the menuconfig issue, you'd still need to move the hidden options that you change out of the block

08:36 <geertu> arnd: right

08:36 <geertu> arnd: Disabling FB allows distros to have a "clean" DRM-only kernel

08:37 <geertu> Enabling FB_DEVICE provides backwards compatibility with fbdev apps for people who need it.

08:37 <arnd> exactly. I think we can do either way, it's a question of semantics

08:37 <geertu> Making both independent makes it easier to enforce a "DRM-only" rule

08:38 <arnd> either CONFIG_FB controls all the legacy support including both /dev/fb and the fbdev drivers, or we have two sepearate top-level options

08:39 <javierm> arnd: agreed with geertu that it would be good to have it independently. Because you could disable all the fbdev drivers but still have /dev/fb* for backward compat but only using DRM fbdev emulation

08:40 <geertu> As DRM still uses fbdev emulation for the console, still extending that to userspace makes sense, IMHO.

08:40 <javierm> geertu: yup

08:40 <geertu> arnd: BTW, you managed to skip EOSS?

08:40 <javierm> arnd: I think that will pause with this series and instead do the fbdev Kconfig cleanup first

08:41 <javierm> once we agree on the structure for the options then adding the FB_CORE symbol should be easier

08:42 <geertu> javierm: makes sense

08:42 <arnd> ok

08:44 <javierm> geertu, arnd: and thanks for your comments. I learned more about Kconfig :)

08:46 <arnd> geertu: yes, I had too much other travel recently so I did not go. For some reason I completely forgot about virtual attendance, I should totally have done that

08:47 <bjdooks> I got there and got covid :/

08:48 <geertu> bjdooks: oops

08:48 <bjdooks> the closest i got was 500M

08:49 <geertu> bjdooks: That's why I didn't meet you there?

08:49 <geertu> bjdooks: take care, recover well!

08:49 <bjdooks> i tested negative on fri morning, but decided not to risk going in. managed to get home sunday despite ryanair's best efforts

08:57 <milkylainen> Tested positive in april. Got worse and worse. Luckily there are antivirals for the infection these days. Got better pretty quick.

08:58 <bjdooks> I thought it was just bad hayfever

09:01 <geertu> I suffer less from hayfever in PRG than at home ;-)

09:06 <javierm> geertu: what do you think of patch #1 in v3. That's an unrelated cleanup that you asked so doesn't need to wait for the other changes

09:08 <geertu> javierm: I guess it's fine. I didn't comment, as I think this is something for the real DRM experts.

09:08 <geertu> I got triggered by the "XFree86 4.1.0" ;-)

09:10 <javierm> geertu: haha, yeah. I noticed that the comment is there from the initial import so really deserved a refresh :)