Disabling /dev/fb0 on TW
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)
On Tuesday 2023-10-10 10:26, Thomas Zimmermann via openSUSE Factory wrote:
fbiterm has been unmaintained for >15 years
8 years give or take; https://github.com/jengelh/fbterm/commits/master
But there's no good drop-in replacement.
kmscon. $ cat /etc/kmscon/kmscon.conf font-name=Consoleet VGA 9x16 font-size=32 (systemctl enable kmsconvt@tty2) It even does CJK (which is what fb(i)term was previously used for).
On Tue, Oct 10, 2023 at 11:36 AM Jan Engelhardt <jengelh@inai.de> wrote:
On Tuesday 2023-10-10 10:26, Thomas Zimmermann via openSUSE Factory wrote:
fbiterm has been unmaintained for >15 years
8 years give or take; https://github.com/jengelh/fbterm/commits/master
But there's no good drop-in replacement.
kmscon.
Last commit over 9 years ago. Yes, I know, it means it is stable :)
$ cat /etc/kmscon/kmscon.conf font-name=Consoleet VGA 9x16 font-size=32
(systemctl enable kmsconvt@tty2)
It even does CJK (which is what fb(i)term was previously used for).
On Tuesday 2023-10-10 10:39, Andrei Borzenkov wrote:
But there's no good drop-in replacement. kmscon. Last commit over 9 years ago. Yes, I know, it means it is stable :)
Huh? https://github.com/Aetf/kmscon/ : 1 year-ish
On Tue, Oct 10, 2023 at 11:42 AM Jan Engelhardt <jengelh@inai.de> wrote:
On Tuesday 2023-10-10 10:39, Andrei Borzenkov wrote:
But there's no good drop-in replacement. kmscon. Last commit over 9 years ago. Yes, I know, it means it is stable :)
Huh? https://github.com/Aetf/kmscon/ : 1 year-ish
Ah, OK, I was not aware of it This is a personal fork from https://www.freedesktop.org/wiki/Software/kmscon, which hasn't been updated since 2014.
вівторок, 10 жовтня 2023 р. 11:35:53 EEST Jan Engelhardt написано:
On Tuesday 2023-10-10 10:26, Thomas Zimmermann via openSUSE Factory wrote:
fbiterm has been unmaintained for >15 years
8 years give or take; https://github.com/jengelh/fbterm/commits/master
I think fb*i*term from [1] was meant, not fbterm. Though fbterm will stop working as well, I think. Some kind of drmterm is needed. [1] https://build.opensuse.org/package/show/openSUSE%3AFactory/xiterm -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський
On Tuesday 2023-10-10 10:44, Mykola Krachkovsky wrote:
вівторок, 10 жовтня 2023 р. 11:35:53 EEST Jan Engelhardt написано:
On Tuesday 2023-10-10 10:26, Thomas Zimmermann via openSUSE Factory wrote:
fbiterm has been unmaintained for >15 years
8 years give or take; https://github.com/jengelh/fbterm/commits/master
I think fb*i*term from [1] was meant, not fbterm. Though fbterm will stop working as well, I think. Some kind of drmterm is needed.
[1] https://build.opensuse.org/package/show/openSUSE%3AFactory/xiterm
Ho hum. xiterm-fbiterm is already strangely broken *today*, with /dev/fb0. It shows the yellow-on-blue startup line on the console and then ... nothing. You can type and exit the shell, but it does not display anything. Switching to X11 and then back to the tty running xiterm-fbiterm is what brings the prompt to the screen (and then it works).
Hi Am 10.10.23 um 10:44 schrieb Mykola Krachkovsky:
вівторок, 10 жовтня 2023 р. 11:35:53 EEST Jan Engelhardt написано:
On Tuesday 2023-10-10 10:26, Thomas Zimmermann via openSUSE Factory wrote:
fbiterm has been unmaintained for >15 years
8 years give or take; https://github.com/jengelh/fbterm/commits/master
I think fb*i*term from [1] was meant, not fbterm. Though fbterm will stop working as well, I think. Some kind of drmterm is needed.
[1] https://build.opensuse.org/package/show/openSUSE%3AFactory/xiterm
Yes, it's fbiterm, not fbterm. Best regards Thomas -- 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)
On Tue, Oct 10, 2023 at 10:35:53AM +0200, Jan Engelhardt wrote:
On Tuesday 2023-10-10 10:26, Thomas Zimmermann via openSUSE Factory wrote:
fbiterm has been unmaintained for >15 years
8 years give or take; https://github.com/jengelh/fbterm/commits/master
But there's no good drop-in replacement.
kmscon.
$ cat /etc/kmscon/kmscon.conf font-name=Consoleet VGA 9x16 font-size=32
(systemctl enable kmsconvt@tty2)
It even does CJK (which is what fb(i)term was previously used for).
It does not, however, use the kernel keymap, and does not support changing the keymap on the fly which is something the installer abuses. There is an laternative that does support this: mlterm-sdl. It is a hassle to set up, though. And nobody cared to create and test the setup for the installer to use mlterm instead of fbiterm. Thanks Michal
On 10/10/2023 09:35, Jan Engelhardt wrote:
On Tuesday 2023-10-10 10:26, Thomas Zimmermann via openSUSE Factory wrote:
fbiterm has been unmaintained for >15 years
8 years give or take; https://github.com/jengelh/fbterm/commits/master
But there's no good drop-in replacement.
kmscon.
$ cat /etc/kmscon/kmscon.conf font-name=Consoleet VGA 9x16 font-size=32
(systemctl enable kmsconvt@tty2)
It even does CJK (which is what fb(i)term was previously used for).
We currently use ksmcon AND fbiterm in jeos-firstboot https://github.com/openSUSE/jeos-firstboot/blob/master/files/usr/sbin/jeos-f... As said before, for CJKZ fonts, currently we default to ksmcon with fbiterm as fallback. When this gets around to be dropped please drop us a line. Thanks, Guilherme
On Thu, Nov 16, 2023 at 02:39:23PM +0000, Guilherme Moro wrote:
On 10/10/2023 09:35, Jan Engelhardt wrote:
On Tuesday 2023-10-10 10:26, Thomas Zimmermann via openSUSE Factory wrote:
fbiterm has been unmaintained for >15 years
8 years give or take; https://github.com/jengelh/fbterm/commits/master
But there's no good drop-in replacement.
kmscon.
$ cat /etc/kmscon/kmscon.conf font-name=Consoleet VGA 9x16 font-size=32
(systemctl enable kmsconvt@tty2)
It even does CJK (which is what fb(i)term was previously used for).
We currently use ksmcon AND fbiterm in jeos-firstboot
https://github.com/openSUSE/jeos-firstboot/blob/master/files/usr/sbin/jeos-f...
As said before, for CJKZ fonts, currently we default to ksmcon with fbiterm as fallback. When this gets around to be dropped please drop us a line.
It's being dropped now - that's what this is saying. There should be no change for kmscon, fbiterm will no longer start. At this point all graphics that you can reasonably use supports KMS which means that the fbiterm fallback is redundant. Thanks Michal
On 16/11/2023 15:30, Michal Suchánek wrote:
On Thu, Nov 16, 2023 at 02:39:23PM +0000, Guilherme Moro wrote:
On 10/10/2023 09:35, Jan Engelhardt wrote:
On Tuesday 2023-10-10 10:26, Thomas Zimmermann via openSUSE Factory wrote:
fbiterm has been unmaintained for >15 years
8 years give or take; https://github.com/jengelh/fbterm/commits/master
But there's no good drop-in replacement.
kmscon.
$ cat /etc/kmscon/kmscon.conf font-name=Consoleet VGA 9x16 font-size=32
(systemctl enable kmsconvt@tty2)
It even does CJK (which is what fb(i)term was previously used for).
We currently use ksmcon AND fbiterm in jeos-firstboot
https://github.com/openSUSE/jeos-firstboot/blob/master/files/usr/sbin/jeos-f...
As said before, for CJKZ fonts, currently we default to ksmcon with fbiterm as fallback. When this gets around to be dropped please drop us a line.
It's being dropped now - that's what this is saying.
There should be no change for kmscon, fbiterm will no longer start.
At this point all graphics that you can reasonably use supports KMS which means that the fbiterm fallback is redundant.
Thanks
Michal
OK, we are prepared to just skip if it does not work, just need to be sure not to try and install the packages during the build of our Minimal-VM images. Thanks, Guilherme Moro
On 10/10/23 11:35, Jan Engelhardt wrote:
On Tuesday 2023-10-10 10:26, Thomas Zimmermann via openSUSE Factory wrote:
fbiterm has been unmaintained for >15 years
8 years give or take; https://github.com/jengelh/fbterm/commits/master
But there's no good drop-in replacement.
kmscon.
Thanks for mentioning this! kmscon seems to work well (finally no squinting while fixing stuff when the GUI won't start).
$ cat /etc/kmscon/kmscon.conf font-name=Consoleet VGA 9x16 font-size=32
(systemctl enable kmsconvt@tty2)
It even does CJK (which is what fb(i)term was previously used for).
Regards, Ahmad Samir
* On 10/10/23 10:26, Thomas Zimmermann via openSUSE Factory wrote:
* What are the effects on userspace programs? Userspace applications run on the desktop via Wayland or X. There will be no change to them.
links and w3m can run directly on the framebuffer and that's very handy if you need a lightweight browser with graphics support for quick browsing if you hosed your usual graphical environment (or are deliberately not using it for some reason). I typically use that a few times a year. Other than that, netsurf with libNSFB comes to mind, but it's correct that this software is not fully part of TW (just netsurf-buildsystem, probably from a time where netsurf was part of TW or was supposed to enter it). I'm critical to this change, even though I understand that the stack is under-maintained, often buggy and dying out (RIP DirectFB, for instance), but it can be highly useful. Mihai
Hi Am 10.10.23 um 10:46 schrieb Mihai Moldovan:
* On 10/10/23 10:26, Thomas Zimmermann via openSUSE Factory wrote:
* What are the effects on userspace programs? Userspace applications run on the desktop via Wayland or X. There will be no change to them.
links and w3m can run directly on the framebuffer and that's very handy if you need a lightweight browser with graphics support for quick browsing if you hosed your usual graphical environment (or are deliberately not using it for some reason).
What is the exact use case? I assume that fbdev is required for displaying images? It looks like links is still actively supported. Couldn't they implement DRM support?
I typically use that a few times a year.
Other than that, netsurf with libNSFB comes to mind, but it's correct that this software is not fully part of TW (just netsurf-buildsystem, probably from a time where netsurf was part of TW or was supposed to enter it).
I'm critical to this change, even though I understand that the stack is under-maintained, often buggy and dying out (RIP DirectFB, for instance), but it can be highly useful.
At some point, the current status quo will be abandoned by Linux distros. It's not just SUSE. But we're still at the first steps. Now is the time to identifying possible problems and dependencies. Best regards Thomas
Mihai
-- 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)
* On 10/10/23 16:49, Thomas Zimmermann via openSUSE Factory wrote:
What is the exact use case?
I assume that fbdev is required for displaying images?
Mostly just browsing the web on VT if I don't want to load into a full graphics session - for instance because I've forgotten to update my (binary) graphics card driver (so X is not starting up), have managed to have a library issue so that the desktop environment is not starting up, just need to apply a kernel patch or change a kernel option, rebuild it and reboot anyway or do other short tasks right before rebooting. The point most often being is that I don't like to start a full desktop sessions if I know that I'll be rebooting in 10 minutes anyway. However, browsing the web without any graphics or mouse support is incredibly frustrating. Even just using a search engine.
It looks like links is still actively supported. Couldn't they implement DRM support?
Probably. Who knows. Nobody has done so yet. I actually haven't found any example of applications using libdrm to draw to VTs, other than toy projects from a few people.
At some point, the current status quo will be abandoned by Linux distros. It's not just SUSE.
Sure, like I've already said, I can see why that would be done. *SuSE systems aren't my daily driver and, frankly, especially Tumbleweed I only ever use in VMs as a development platform and I've never used this functionality there yet.
But we're still at the first steps. Now is the time to identifying possible problems and dependencies.
I figure that in the long run, direct FB access will vanish, just like DirectFB died. There are replacements, but they are mostly used for embedded systems and actual users on desktop systems are scarce. Alternatives, like libdrm, exist, but aren't in demand or implemented in applications. That's not something *SuSE should care about, though. I'm just voicing up as a one the very, very, very few and very, very infrequent user of that feature. :) Mihai
On Thursday 2023-11-02 07:00, Mihai Moldovan wrote:
* On 10/10/23 16:49, Thomas Zimmermann via openSUSE Factory wrote:
It looks like links is still actively supported. Couldn't they implement DRM support [for e.g. w3m/kmscon]?
Probably. Who knows. Nobody has done so yet. I actually haven't found any example of applications using libdrm to draw to VTs, other than toy projects from a few people.
Could you share links to said toy projects?
* On 11/2/23 07:24, Jan Engelhardt wrote:
Could you share links to said toy projects?
Just the stuff I found by quickly searching for it: This for directly drawing to a VT: https://williamaadams.wordpress.com/2015/09/26/spelunking-linux-drawing-on-l... A tutorial of sorts for the same thing: https://embear.ch/blog/drm-framebuffer Mostly a discussion of how to use OpenGL ES via libdrm and mentioning SRM: https://stackoverflow.com/questions/23139886/how-to-create-opengl-context-vi... The only prominent user I know and naturally have forgotten about is Plymouth, which should also be using libdrm to draw the splash image/video directly to VTs. Mihai
On Tue, Oct 10, 2023 at 10:46:36AM +0200, Mihai Moldovan wrote:
* On 10/10/23 10:26, Thomas Zimmermann via openSUSE Factory wrote:
* What are the effects on userspace programs? Userspace applications run on the desktop via Wayland or X. There will be no change to them.
links and w3m can run directly on the framebuffer and that's very handy if you need a lightweight browser with graphics support for quick browsing if you hosed your usual graphical environment (or are deliberately not using it for some reason).
At least some of these support SDL as display driver, and that in turn supports DRM backend. With that you can still use the program directly on the console. Thanks Michal
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
Hi, Sorry I missed this thread while I was travelling On 10/10/23 18:56, Thomas Zimmermann via openSUSE Factory wrote: particular I have used "fbi" to draw images directly to the 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. -- 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
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
On 10/10/23 18:56, Thomas Zimmermann via openSUSE Factory wrote: particular I have used "fbi" to draw images directly to the 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? Best regards Thomas
-- 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)
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
On 10/10/23 18:56, Thomas Zimmermann via openSUSE Factory wrote: particular I have used "fbi" to draw images directly to the 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. 1. https://www.waveshare.com/3.2inch-RPi-LCD-B.htm -- 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
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.
15 years and is ready for retirement. But there's no good drop-in replacement. I propose to simply remove fbiterm and let
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 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? 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. Thanks Michal
Hi
Am 20.11.23 um 12:15 schrieb Michal Suchánek:
> 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
>>>>
>>>> On 10/10/23 18:56, Thomas Zimmermann via openSUSE Factory wrote:
>>>>> 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
>>>> 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.
>>
>> 1. https://www.waveshare.com/3.2inch-RPi-LCD-B.htm
>
> Hello,
>
> does the driver for this display sypport DRM?
I cannot find anything on the actual chip. From the little information,
I think this is a DRM driver.
> git grep -i waveshare
Documentation/devicetree/bindings/display/ilitek,ili9486.yaml:
# Waveshare 3.5" 320x480 Color TFT LCD
Documentation/devicetree/bindings/display/ilitek,ili9486.yaml:
- waveshare,rpi-lcd-35
Documentation/devicetree/bindings/display/ilitek,ili9486.yaml:
compatible = "waveshare,rpi-lcd-35", "ilitek,ili9486";
Documentation/devicetree/bindings/vendor-prefixes.yaml: "^waveshare,.*":
Documentation/devicetree/bindings/vendor-prefixes.yaml: description:
Waveshare Electronics
drivers/gpu/drm/tiny/Kconfig: * RPILCD 3.5" 320x480 TFT (Waveshare 3.5")
drivers/gpu/drm/tiny/ili9486.c: * The PiScreen/waveshare rpi-lcd-35 has
a SPI to 16-bit parallel bus converter
drivers/gpu/drm/tiny/ili9486.c:static int waveshare_command(struct
mipi_dbi *mipi, u8 *cmd, u8 *par,
drivers/gpu/drm/tiny/ili9486.c:static void waveshare_enable(struct
drm_simple_display_pipe *pipe,
drivers/gpu/drm/tiny/ili9486.c:static const struct
drm_simple_display_pipe_funcs waveshare_pipe_funcs = {
drivers/gpu/drm/tiny/ili9486.c:
DRM_MIPI_DBI_SIMPLE_DISPLAY_PIPE_FUNCS(waveshare_enable),
drivers/gpu/drm/tiny/ili9486.c:static const struct drm_display_mode
waveshare_mode = {
drivers/gpu/drm/tiny/ili9486.c: { .compatible = "waveshare,rpi-lcd-35" },
drivers/gpu/drm/tiny/ili9486.c: dbi->command = waveshare_command;
drivers/gpu/drm/tiny/ili9486.c: ret = mipi_dbi_dev_init(dbidev,
&waveshare_pipe_funcs,
drivers/gpu/drm/tiny/ili9486.c: &waveshare_mode,
rotation);
I don't find anything under drivers/video.
>
> 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.
I think we should promote to port to SDL2. libdrm is just a wrapper
around the kernel ioctls. That's maybe a bit too complex to work with
for most simple programs. But the difference between libdrm and raw
fbdev is mostly in API names and SDL is not more complex to program.
Best regards
Thomas
>
> Thanks
>
> Michal
--
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)
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.
15 years and is ready for retirement. But there's no good drop-in replacement. I propose to simply remove fbiterm and let
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 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 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, 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
Hi Am 20.11.23 um 13:18 schrieb Simon Lees:
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*
Which driver are you using? Best regards Thomas
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 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, 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
-- 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)
On 11/20/23 22:54, Thomas Zimmermann via openSUSE Factory wrote:
Hi
Am 20.11.23 um 13:18 schrieb Simon Lees:
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
On 10/10/23 18:56, Thomas Zimmermann via openSUSE Factory wrote: > 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 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*
Which driver are you using?
Currently fbdev, i've seen similarly designed newer displays using tinyDRM, so that maybe an alternative but to date I couldn't find any information of someone implementing support for this display in that driver. -- 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
Hi Am 21.11.23 um 00:20 schrieb Simon Lees: [...]
does the driver for this display sypport DRM?
Not last time I checked, hence the need for /dev/fb*
Which driver are you using?
Currently fbdev, i've seen similarly designed newer displays using tinyDRM, so that maybe an alternative but to date I couldn't find any information of someone implementing support for this display in that driver.
With the display enabled, what is the output of cat /proc/fb ? Best regards Thomas -- 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)
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
On 11/20/23 22:59, Michal Suchánek wrote:
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
On 10/10/23 18:56, Thomas Zimmermann via openSUSE Factory wrote: > 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 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...
Yes it has support for both drm and traditional framebuffer, the thing stopping me making the swap is driver support rather then the need for specific userspace applications. -- 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
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)
On 10/22/24 4:43 AM, Thomas Zimmermann via openSUSE Factory wrote:
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.
Hi Thomas, xf86-video-fbdev was installed by default when TW was installed so I assume at some point that package will be dropped from the repos and removed from systems. When that happens will the Xorg modesetting driver be auto installed ? If not, what is the name for that package ? Is it xorg-x11-driver-video ? Thanks Joe
On Tue, Oct 22, 2024 at 6:36 PM Joe Salmeri <jmscdba@gmail.com> wrote:
On 10/22/24 4:43 AM, Thomas Zimmermann via openSUSE Factory wrote:
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.
Hi Thomas,
xf86-video-fbdev was installed by default when TW was installed so I assume at some point that package will be dropped from the repos and removed from systems.
When that happens will the Xorg modesetting driver be auto installed ?
If not, what is the name for that package ?
Is it xorg-x11-driver-video ?
It is bundled in the xorg-x11-server package. You don't need a separate driver package. -- 真実はいつも一つ！/ Always, there's only one truth!
Joe Salmeri composed on 2024-10-22 18:35 (UTC-0400):
xf86-video-fbdev was installed by default when TW was installed so I assume at some point that package will be dropped from the repos and removed from systems.
When that happens will the Xorg modesetting driver be auto installed ?
If not, what is the name for that package ?
Is it xorg-x11-driver-video ?
None of the above. It's already installed if you have X installed, part of xorg-x11-server. You may already see X check if it will load:
grep modesetting_drv /var/log/Xorg.0.log [ 9.338] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so # -- Evolution as taught in public schools is, like religion, based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Hi Am 23.10.24 um 00:35 schrieb Joe Salmeri:
On 10/22/24 4:43 AM, Thomas Zimmermann via openSUSE Factory wrote:
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.
Hi Thomas,
xf86-video-fbdev was installed by default when TW was installed so I assume at some point that package will be dropped from the repos and removed from systems.
When that happens will the Xorg modesetting driver be auto installed ?
If not, what is the name for that package ?
As the other commenters said, that driver is part of the Xorg server itself. No need to install anything else. It's auto-loaded if nothing else has been configured. So if you did not modify your xorg.conf, you should already be using it. Best regards Thomas
Is it xorg-x11-driver-video ?
Thanks
Joe
-- -- 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)
participants (12)
-
Ahmad Samir -
Andrei Borzenkov -
Felix Miata -
Guilherme Moro -
Jan Engelhardt -
Joe Salmeri -
Michal Suchánek -
Mihai Moldovan -
Mykola Krachkovsky -
Neal Gompa -
Simon Lees -
Thomas Zimmermann