kernel/linux.git/drivers/video/console/Kconfig, branch v6.18.21

mdacon: rework dependency list

2025-03-26T21:39:20+00:00

mdacon has roughly the same dependencies as vgacon but expresses them as a negative list instead of a positive list, with the only practical difference being PowerPC/CHRP, which uses vga16fb instead of vgacon. The CONFIG_MDA_CONSOLE description advises to only turn it on when vgacon is also used because MDA/Hercules-only systems should be using vgacon instead, so just change the list to enforce that directly for simplicity. The probing was broken from 2002 to 2008, this improves on the fix that was added then: If vgacon is a loadable module, then mdacon cannot be built-in now, and the list of systems that support vgacon is carried over. Fixes: 0b9cf3aa6b1e ("mdacon messing up default vc's - set default to vc13-16 again") Signed-off-by: Arnd Bergmann Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller

dummycon: fix default rows/cols

2025-03-26T21:39:20+00:00

dummycon fails to build on ARM/footbridge when the VGA console is disabled, since I got the dependencies slightly wrong in a previous patch: drivers/video/console/dummycon.c: In function 'dummycon_init': drivers/video/console/dummycon.c:27:25: error: 'CONFIG_DUMMY_CONSOLE_COLUMNS' undeclared (first use in this function); did you mean 'CONFIG_DUMMY_CONSOLE'? 27 | #define DUMMY_COLUMNS CONFIG_DUMMY_CONSOLE_COLUMNS drivers/video/console/dummycon.c:28:25: error: 'CONFIG_DUMMY_CONSOLE_ROWS' undeclared (first use in this function); did you mean 'CONFIG_DUMMY_CONSOLE'? 28 | #define DUMMY_ROWS CONFIG_DUMMY_CONSOLE_ROWS This only showed up after many thousand randconfig builds on Arm, and doesn't matter in practice, but should still be fixed. Address it by using the default row/columns on footbridge after all in that corner case. Fixes: 4293b0925149 ("dummycon: limit Arm console size hack to footbridge") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202409151512.LML1slol-lkp@intel.com/ Signed-off-by: Arnd Bergmann Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller

dummycon: only build module if there are users

2025-03-26T21:39:20+00:00

Dummycon is used as a fallback conswitchp for vgacon and fbcon in the VT code, and there are no references to it if all three are disabled, so just leave it out of the kernel image for configurations without those. Signed-off-by: Arnd Bergmann Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller

vgacon: drop IA64 reference in VGA_CONSOLE dependency list

2023-11-28T19:04:20+00:00

Commit e9e3300b6e77 ("vgacon: rework Kconfig dependencies") turns the dependencies into a positive list of supported architectures, which includes the IA64 architecture, but in the meantime, this architecture is removed in commit cf8e8658100d ("arch: Remove Itanium (IA-64) architecture"). Drop the reference to IA64 architecture in the dependency list of the VGA_CONSOLE config definition. Signed-off-by: Lukas Bulwahn Acked-by: Arnd Bergmann Reviewed-by: Javier Martinez Canillas Link: https://lore.kernel.org/r/20231110114400.30882-1-lukas.bulwahn@gmail.com Signed-off-by: Greg Kroah-Hartman

dummycon: limit Arm console size hack to footbridge

2023-10-17T08:17:02+00:00

The dummycon default console size used to be determined by architecture, but now this is a Kconfig setting on everything except ARM. Tracing this back in the historic git trees, this was used to match the size of VGA console or VGA framebuffer on early machines, but nowadays that code is no longer used, except probably on the old footbridge/netwinder since that is the only one that supports vgacon. On machines with a framebuffer, booting with DT so far results in always using the hardcoded 80x30 size in dummycon, while on ATAGS the setting can come from a bootloader specific override. Both seem to be worse choices than the Kconfig setting, since the actual text size for fbcon also depends on the selected font. Make this work the same way as everywhere else and use the normal Kconfig setting, except for the footbridge with vgacon, which keeps using the traditional code. If vgacon is disabled, footbridge can also ignore the setting. This means the screen_info only has to be provided when either vgacon or EFI are enabled now. To limit the amount of surprises on Arm, change the Kconfig default to the previously used 80x30 setting instead of the usual 80x25. Reviewed-by: Thomas Zimmermann Tested-by: Linus Walleij Reviewed-by: Javier Martinez Canillas Acked-by: Helge Deller Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20231009211845.3136536-4-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman

vgacon: rework Kconfig dependencies

2023-10-17T08:17:01+00:00

The list of dependencies here is phrased as an opt-out, but this is missing a lot of architectures that don't actually support VGA consoles, and some of the entries are stale: - powerpc used to support VGA consoles in the old arch/ppc codebase, but the merged arch/powerpc never did - arm lists footbridge, integrator and netwinder, but netwinder is actually part of footbridge, and integrator does not appear to have an actual VGA hardware, or list it in its ATAG or DT. - mips has a few platforms (malta, sibyte, and sni) that initialize screen_info, on everything else the console is selected but cannot actually work. - csky, hexgagon, loongarch, nios2, riscv and xtensa are not listed in the opt-out table and declare a screen_info to allow building vga_con, but this cannot work because the console is never selected. Replace this with an opt-in table that lists only the platforms that remain. This is effectively x86, plus a couple of historic workstation and server machines that reused parts of the x86 system architecture. Reviewed-by: Javier Martinez Canillas Reviewed-by: Thomas Zimmermann Reviewed-by: Khalid Aziz Acked-by: Helge Deller Signed-off-by: Arnd Bergmann Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20231009211845.3136536-2-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman

drm: fix up fbdev Kconfig defaults

2023-09-18T08:52:55+00:00

As a result of the recent Kconfig reworks, the default settings for the framebuffer interfaces changed in unexpected ways: Configurations that leave CONFIG_FB disabled but use DRM now get DRM_FBDEV_EMULATION by default. This also turns on the deprecated /dev/fb device nodes for machines that don't actually want it. In turn, configurations that previously had DRM_FBDEV_EMULATION enabled now only get the /dev/fb front-end but not the more useful framebuffer console, which is not selected any more. We had previously decided that any combination of the three frontends (FB_DEVICE, FRAMEBUFFER_CONSOLE and LOGO) should be selectable, but the new default settings mean that a lot of defconfig files would have to get adapted. Change the defaults back to what they were in Linux 6.5: - Leave DRM_FBDEV_EMULATION turned off unless CONFIG_FB is enabled. Previously this was a hard dependency but now the two are independent. However, configurations that enable CONFIG_FB probably also want to keep the emulation for DRM, while those without FB presumably did that intentionally in the past. - Leave FB_DEVICE turned off for FB=n. Following the same logic, the deprecated option should not automatically get enabled here, most users that had FB turned off in the past do not want it, even if they want the console - Turn the FRAMEBUFFER_CONSOLE option on if DRM_FBDEV_EMULATION is set to avoid having to change defconfig files that relied on it being selected unconditionally in the past. This also makes sense since both LOGO and FB_DEVICE are now disabled by default for builds without CONFIG_FB, but DRM_FBDEV_EMULATION would make no sense if all three are disabled. Fixes: a5ae331edb02b ("drm: Drop select FRAMEBUFFER_CONSOLE for DRM_FBDEV_EMULATION") Fixes: 701d2054fa317 ("fbdev: Make support for userspace interfaces configurable") Reported-by: Geert Uytterhoeven Signed-off-by: Arnd Bergmann Reviewed-by: Javier Martinez Canillas Reviewed-by: Geert Uytterhoeven Acked-by: Thomas Zimmermann Signed-off-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20230911205338.2385278-1-arnd@kernel.org

fbdev: Split frame buffer support in FB and FB_CORE symbols

2023-07-22T10:25:04+00:00

Currently the CONFIG_FB option has to be enabled even if no legacy fbdev drivers are needed (e.g: only to have support for framebuffer consoles). The DRM subsystem has a fbdev emulation layer, but depends on CONFIG_FB and so it can only be enabled if that dependency is enabled as well. That means fbdev drivers have to be explicitly disabled if users want to enable CONFIG_FB, only to use fbcon and/or the DRM fbdev emulation layer. This patch introduces a non-visible CONFIG_FB_CORE symbol that could be enabled just to have core support needed for CONFIG_DRM_FBDEV_EMULATION, allowing CONFIG_FB to be disabled (and automatically disabling all the fbdev drivers). Nothing from fb_backlight.o and fbmon.o is used by the DRM fbdev emulation layer so these two objects can be compiled out when CONFIG_FB is disabled. Signed-off-by: Javier Martinez Canillas Reviewed-by: Arnd Bergmann Tested-by: Arnd Bergmann Acked-by: Helge Deller Link: https://patchwork.freedesktop.org/patch/msgid/20230719081544.741051-4-javierm@redhat.com

video: Move HP PARISC STI core code to shared location

2023-04-20T08:04:51+00:00

STI core files have been located in console and fbdev code. Move the source code and header to the directories for video helpers. Also update the config and build rules such that the code depends on the config symbol CONFIG_STI_CORE, which STI console and STI framebuffer select automatically. Cleans up the console makefile and prepares PARISC to implement fb_is_primary_device() within the arch/ directory. No functional changes. Signed-off-by: Thomas Zimmermann Acked-by: Arnd Bergmann Acked-by: Helge Deller Link: https://patchwork.freedesktop.org/patch/msgid/20230417125651.25126-12-tzimmermann@suse.de

drm: Implement DRM aperture helpers under video/

2022-06-27T09:07:55+00:00

Implement DRM's aperture helpers under video/ for sharing with other sub-systems. Remove DRM-isms from the interface. The helpers track the ownership of framebuffer apertures and provide hand-over from firmware, such as EFI and VESA, to native graphics drivers. Other subsystems, such as fbdev and vfio, also have to maintain ownership of framebuffer apertures. Moving DRM's aperture helpers to a more public location allows all subsystems to interact with each other and share a common implementation. The aperture helpers are selected by the various firmware drivers within DRM and fbdev, and the VGA text-console driver. The original DRM interface is kept in place for use by DRM drivers. v3: * prefix all interfaces with aperture_ (Javier) * rework and simplify documentation (Javier) * rename struct dev_aperture to struct aperture_range * rebase onto latest DRM * update MAINTAINERS entry Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Tested-by: Laszlo Ersek Link: https://patchwork.freedesktop.org/patch/msgid/20220622140134.12763-3-tzimmermann@suse.de