linux/drivers/video/console, branch v6.7

console: fix up ARM screen_info reference

2023-10-17T14:34:02Z

Separating the VGA console screen_info from the EFI one unfortunately caused a build failure for footbridge that I had never caught with randconfig builds: arch/arm/kernel/setup.c:932:27: error: static declaration of 'vgacon_screen_info' follows non-static declaration 932 | static struct screen_info vgacon_screen_info = { | ^~~~~~~~~~~~~~~~~~ In file included from arch/arm/kernel/setup.c:44: arch/arm/include/asm/setup.h:40:27: note: previous declaration of 'vgacon_screen_info' with type 'struct screen_info' 40 | extern struct screen_info vgacon_screen_info; | ^~~~~~~~~~~~~~~~~~ arm-linux-gnueabi-ld: drivers/video/console/dummycon.o: in function `dummycon_init': dummycon.c:(.text+0xe4): undefined reference to `screen_info' Make sure the variable is global to avoid the conflict with the extern declaration, and make it work in dummycon.c Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20231017093947.3627976-2-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman

vgacon: remove screen_info dependency

2023-10-17T08:17:02Z

The vga console driver is fairly self-contained, and only used by architectures that explicitly initialize the screen_info settings. Chance every instance that picks the vga console by setting conswitchp to call a function instead, and pass a reference to the screen_info there. Reviewed-by: Javier Martinez Canillas Acked-by: Khalid Azzi Acked-by: Helge Deller Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20231009211845.3136536-6-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman

dummycon: limit Arm console size hack to footbridge

2023-10-17T08:17:02Z

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:01Z

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:55Z

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

BackMerge tag 'v6.5-rc7' into drm-next

2023-08-23T21:26:06Z

Linux 6.5-rc7 This is needed for the CI stuff and the msm pull has fixes in it. Signed-off-by: Dave Airlie

fbdev: Split frame buffer support in FB and FB_CORE symbols

2023-07-22T10:25:04Z

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

sticon: make sticon_set_def_font() void and remove op parameter

2023-07-20T05:43:11Z

sticon_set_def_font() always returns 0, so make it void. And remove an unused 'op' parameter. Signed-off-by: "Jiri Slaby (SUSE)" Cc: "James E.J. Bottomley" Cc: Helge Deller Cc: linux-parisc@vger.kernel.org Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Helge Deller

vgacon: cache vc_cell_height in vgacon_cursor()

2023-07-20T05:43:11Z

There are many places c->vc_cell_height is used in the code of vgacon_cursor(). Caching the value to a local variable makes the code much easier to follow. Signed-off-by: "Jiri Slaby (SUSE)" Cc: Helge Deller Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Helge Deller

vgacon: let vgacon_doresize() return void

2023-07-20T05:43:11Z

The return value is neither used, nor vgacon_doresize() returns an error. So change the reurn type to void. Signed-off-by: "Jiri Slaby (SUSE)" Cc: Helge Deller Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Helge Deller