On Mon, Nov 20, 2023 at 10:48:02PM +1030, Simon Lees wrote:
On 11/20/23 21:45, Michal Suchánek wrote:
On Mon, Nov 20, 2023 at 12:42:02PM +1030, Simon Lees wrote:
On 11/14/23 18:36, Thomas Zimmermann via openSUSE Factory wrote:
Hi
Am 02.11.23 um 07:45 schrieb Simon Lees:
Hi,
Sorry I missed this thread while I was travelling
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. I have usecases with raspberry pi's and other similar devices where I have used SPI based TFT displays outputting directly to /dev/fb0, In particular I have used "fbi" to draw images directly to the
On 10/10/23 18:56, Thomas Zimmermann via openSUSE Factory wrote: framebuffer, efl (Enlightenment Foundation Libraries) apps can also render directly to the framebuffer.
I haven't had mine working that recently so I can't comment on the state of the driver I was using but given the prevalence of such devices in the raspberry pi ecosystem it probably makes alot of sense to keep this feature enabled atleast for ARM kernels.
Which displays (brand, model) do you use?
Do you need a new driver for the displays? Or do you need a user space that does not require /dev/fb?
Sorry for taking a while to get back to you, i'm using a 3.2" waveshare spotpear [1], I last had it running with the fbdev driver (its a while since I updated the project.
Generally I have been using it with programs that can directly use /dev/fb1 rather then running a full X11 instance because its mostly just for displaying status messages etc, although during testing I setup a full X11 environment but generally most X11 desktop's don't work well on a screen that small and it makes my life simpler because I just setup X11 on the rpi's hdmi port for if I really want it to use more advanced debugging tools or to setup the network configuration etc.
Hello,
does the driver for this display sypport DRM?
Not last time I checked, hence the need for /dev/fb*
There has been some effort put into making these small displays compatible with DRM but I don't have this particular display so I cannot be sure that the driver is available and enabled in the Tumbleweed kernel for this particular model.
While it's possible to use /dev/fb1 there is also libdrm for using the drm interface directly, and liblaries like SDL that can use either.
You don't say what specific program you use so I can't tell what specific interface(s) it can use, either.
At times i've been really simple and used fbi [1], to display simple status
There is fim which can use SDL (untested) http://www.enlightenment.org/develop/legacy/api/c/start#group__Ecore__Drm__G...
images, its quick simple and easy. If I could use drm then there are many other ways of doing this i'm sure.
Additionally the Enlightenment toolkit (efl)[2]. Can render directly to framebuffer, so at times i've used its terminal emulator to display output, using the DRM API http://www.enlightenment.org/develop/legacy/api/c/start#group__Ecore__Drm__G... long term I was planning to write a full status monitor app in EFL which would also allow me to move it to X11 or wayland based things later if I move to hardware that supports it.
1. https://manpages.ubuntu.com/manpages/xenial/man1/fbi.1.html 2. http://www.enlightenment.org/about
-- Simon Lees (Simotek) http://simotek.net
Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B