Hi, Sorry for the late reply, there is always someone doing something unusual and this time its me for a hobby project hence not getting to testing until now. On 12/23/21 20:30, Thomas Zimmermann wrote:
tl;dr: Enable DRM for all graphics output and retire fbdev drivers in TW.
Hi!
For quit a few releases, Linux' DRM stack has been able to provide display output from the early boot stages on. Next year, we want to modernize Tumbleweed's graphics stack and use DRM for all graphics output.
To get graphics output during the early stages of booting, Linux still uses fbdev infrastructure and a few HW-independed drivers, such as efifb and vesafb.
This functionality is now available in DRM as well. We will switch early-boot graphics from fbdev to DRM and retire the related fbdev drivers. Fbdev userspace interfaces (i.e., /dev/fb0) will still be available via the new driver.
The change has no effect on graphics output of the fully booted machine. Just as now, at some point during boot, a hardware-specific driver, such as amdgpu, i915, etc., will take over the display.
Connected to the raspberry pi on my Robot I have a small 3.2" display [1] (or a clone / older version) it connects via SPI on the raspberry pi's GPIO header. In the past i've had it working with the overlay at [2] and the fbtft driver. This kinda setup is pretty common in the embedded / hobbyist world, I don't use a desktop or anything just simple status apps using the framebuffer directly on the other hand it wouldn't be the end of the world if I moved to Qt. Today I finally got a chance to update and as of now I no longer have an /dev/fb1 (/dev/fb0 is hdmi) is that expected with my current setup? I had other issues with the update and had to grab a fresh image and re add my overlay and raspbery pi config so there is also a chance I missed something setting it up again. I've put some dmesg output from the older system the new system shows nothing and below that is an fbi command I use for testing. If you'd like I can also open a ticket on bugzilla. Cheers Simon dmesg | grep fb [ 21.508662] efifb: probing for efifb [ 21.508916] efifb: framebuffer at 0x3e402000, using 8100k, total 8100k [ 21.508929] efifb: mode is 1920x1080x32, linelength=7680, pages=1 [ 21.508941] efifb: scrolling: redraw [ 21.508946] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [ 21.558204] fb0: EFI VGA frame buffer device [ 59.468595] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 59.714749] fb_ili9340: module is from the staging directory, the quality is unknown, you have been warned. [ 59.716023] fb_ili9340 spi0.0: fbtft_property_value: buswidth = 8 [ 59.716049] fb_ili9340 spi0.0: fbtft_property_value: debug = 0 [ 59.716063] fb_ili9340 spi0.0: fbtft_property_value: rotate = 270 [ 59.716079] fb_ili9340 spi0.0: fbtft_property_value: fps = 25 [ 59.716093] fb_ili9340 spi0.0: fbtft_property_value: txbuflen = 32768 [ 61.352903] graphics fb1: fb_ili9340 frame buffer, 320x240, 150 KiB video memory, 32 KiB buffer memory, fps=25, spi0.0 at 16 MHz [ 67.125256] fb0: switching to vc4drmfb from EFI VGA [ 67.347158] vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device sudo fbi -T 13 -d /dev/fb1 --noverbose 1-110313112A3.jpg 1. https://www.waveshare.com/wiki/3.2inch_RPi_LCD_(B) 2. https://github.com/swkim01/waveshare-dtoverlays -- 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