Hi, after this thread has been around for a year, I intent to finally disable fbdev userspace interfaces on TW. The tracker bug is boo#1212947. [1] Most users will not notice the change. Here are some notes on the topics that came up wrt fbdev interfaces. * The only program in TW requiring fbdev interfaces, the installer's fbiterm, has been removed a while ago. [2] * The fbcon device will still be available and remain available. If you require console rotation for your text-mode console, please use echo {0, 1, 2, 3} > /sys/class/graphics/fbcon/{rotate, rotate_all} where 0 to 3 represent rotation angles from 0 to 270 degrees. If you still set up rotation via /sys/class/graphics/fb0/rotate, that interface will be gone. * Users of xf86-video-fbdev should upgrade to Xorg's modesetting driver. * A very small number of people reported use cases where a text-mode program draws to the display via /dev/fb0. This will no longer be possible. The easiest solution is to port that software to SDL2, which supports various outputs including fbdev and DRM. No compositor is required for DRM support. Best regards Thomas [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1212947 [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1224053 Am 10.10.23 um 10:26 schrieb Thomas Zimmermann:
tl;dr: Disable fbdev userspace interfaces on TW
Hi,
the upcoming Linux kernel v6.6 will contain the option to disable fbdev userspace interfaces in the kernel configuration. [1] I intent to enable this and thereby switch off /dev/fb0 et al. The tracker bug is boo#1212947. [2]
* Why? The old fbdev subsystem is an endless source of bugs. For example, we recently had an out-of-bounds access in the fbdev emulation, where userspace could write beyond the end of the framebuffer memory. [3] Fbdev is under-maintained. I've been doing improvements in recent kernel releases, but only where it benefits the DRM subsystem. Disabling fbdev userspace interfaces will also help weeding out any programs that still contain hard dependencies on them.
* What changes? Enabling the new kernel option disables all fbdev userspace interfaces. These are
* the device files, such as /dev/fb0 * the sys files under /sys/class/graphics/fb[0-9]+ * /proc/fb
* What are the effects on userspace programs? Userspace applications run on the desktop via Wayland or X. There will be no change to them. Xorg and Wayland compositors run on DRM interfaces. A few programs run on SDL, which has no dependency on fbdev either. Any fbdev support in these mid-layer components should be disabled as well.
There's one known affected program: TW's text-mode installer can use the tool fbiterm to display CJK symbols during installation. This comes from a time when some low-end systems where not able to boot graphics installation. fbiterm has been unmaintained for >15 years and is ready for retirement. But there's no good drop-in replacement. I propose to simply remove fbiterm and let the graphics installer handle CJK.
* What about the framebuffer console? The kernel-provided framebuffer console does not change. The kernel will still show the regular console. Userspace interfaces in /sys/class/graphics/fbcon are still available.
For questions and discussion, please comment here or in boo#1212947.
Best regards Thomas
[1] https://elixir.bootlin.com/linux/v6.6-rc1/source/drivers/video/fbdev/core/Kc... [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1212947 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.6-rc5&id=c8687694bb1f5c48134f152f8c5c2e53483eb99d
-- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)