On Thu, 2021-12-23 at 12:28 +0100, Carlos E. R. wrote:

On 23/12/2021 11.00, Thomas Zimmermann wrote:

...

tl;dr: Enable DRM for all graphics output and retire fbdev drivers in TW.

DRM? Digital Rights Management?

I guess not, so could you spell it out, please?

https://en.wikipedia.org/wiki/Direct_Rendering_Manager

Am Donnerstag, 23. Dezember 2021, 12:28:22 CET schrieb Carlos E. R.:

On 23/12/2021 11.00, Thomas Zimmermann wrote:

...

tl;dr: Enable DRM for all graphics output and retire fbdev drivers in TW.

DRM? Digital Rights Management?

Digital *Restrictions* Management should be the correct spelling SCNR Axel

Hi Am 23.12.21 um 13:06 schrieb Konstantin Voinov:

Hi!

Will it work with Nvidia?

Only Nvidia can really answer this question. If you have the time and expertise, we'd appreciate if you could give it a try with your hardware and report back the results. The instructions are in my original mail. Best regards Thomas

On 2021-12-23 20:00, Thomas Zimmermann wrote:

...

tl;dr: Enable DRM for all graphics output and retire fbdev drivers in TW.

Hi!

...

Best regards Thomas

-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

Larry Finger composed on 2021-12-23 13:01 (UTC-0600):

Thomas Zimmermann wrote:

...

We welcome bug reports. If you find issues, please leave a comment in boo#1193250

...

  https://bugzilla.opensuse.org/show_bug.cgi?id=1193250

No bugs found on my Toshiba laptop with an i915 graphics adapter. I noticed no difference in the boot sequence.

i915 has two meanings: 1-kernel driver for all non-ancient Intel IGPs 2-i915 GMA 950 graphics on Intel northbridge chip from 2004-2005, which only works with 32bit Pentium 4s and Celerons, after which the i915 kernel driver was named So, did you test on 32bit TW with your i915 IGP, or is some other IGP in your Toshiba, and if so, which? e.g.: inxi -Ga -- 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 24.12.21 um 00:52 schrieb Larry Finger:

On 12/23/21 16:32, Felix Miata wrote:

...

Larry Finger composed on 2021-12-23 13:01 (UTC-0600):

...

Thomas Zimmermann wrote:

...

...

We welcome bug reports. If you find issues, please leave a comment in boo#1193250

...

...

    https://bugzilla.opensuse.org/show_bug.cgi?id=1193250

...

No bugs found on my Toshiba laptop with an i915 graphics adapter. I noticed no difference in the boot sequence.

i915 has two meanings: 1-kernel driver for all non-ancient Intel IGPs 2-i915 GMA 950 graphics on Intel northbridge chip from 2004-2005, which only works with 32bit Pentium 4s and Celerons, after which the i915 kernel driver was named

So, did you test on 32bit TW with your i915 IGP, or is some other IGP in your Toshiba, and if so, which? e.g.:

inxi -Ga Reports: Graphics:  Device-1: Intel 4th Gen Core Processor Integrated Graphics vendor: Toshiba driver: i915 v: kernel bus-ID: 00:02.0            chip-ID: 8086:0416 class-ID: 0300            Device-2: Chicony TOSHIBA Web Camera - FHD type: USB driver: uvcvideo bus-ID: 3-10:2 chip-ID: 04f2:b3b2            class-ID: 0e02 serial: 0x0001            Display: x11 server: X.org 1.21.1.2 compositor: kwin_x11 driver: loaded: modesetting unloaded: fbdev,vesa            alternate: intel resolution:            OpenGL: renderer: Mesa DRI Intel HD Graphics 4600 (HSW GT2) v: 4.5 Mesa 21.3.1 compat-v: 3.0 direct render: Yes

This is a 64-bit system.

Thanks for testing. Best regards Thomas

Larry

-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

On Thursday 2021-12-23 20:17, Frans de Boer wrote:

On 23/12/2021 11:00, Thomas Zimmermann wrote:

...

tl;dr: Enable DRM for all graphics output and retire fbdev drivers in TW.

I just wonder what this implies for text based output only?

Hm... disabling efifb would mean you get no kernel console on UEFI until e.g. i915 is successfully loaded. Considering that i915 is not part of the initramfs normally and also requires firmware files (which usually are kernel-version specific), something as simple as upgrading the kernel (without kernel-firmware) could potentially produce black screens. That is not a great prospect.

Another consequence is that the kernel footprint will be raised again due to

DirectRendering is practically already present at all times: The moment i915.ko/amdgpu.ko/etc. (or whatever it is you have) loads, and it loads irrespective of whether you use X11 or not, vesafb/efifb gets switched out for inteldrmfb/amdgpudrmfb/etc. (the names were changed in kernel commit 97c9bfe3f6605d41eb8f1206e6e0f62b31ba15d6). Therefore you lose nothing for which you already paid since practically KMS first became available.

On 24/12/2021 09.28, Thomas Zimmermann wrote:

Hi

Am 23.12.21 um 23:18 schrieb Jan Engelhardt:

...

On Thursday 2021-12-23 20:17, Frans de Boer wrote:

...

On 23/12/2021 11:00, Thomas Zimmermann wrote:

...

...

...

Another consequence is that the kernel footprint will be raised again due to

DirectRendering is practically already present at all times: The moment i915.ko/amdgpu.ko/etc. (or whatever it is you have) loads, and it loads irrespective of whether you use X11 or not, vesafb/efifb gets switched out for inteldrmfb/amdgpudrmfb/etc. (the names were changed in kernel commit 97c9bfe3f6605d41eb8f1206e6e0f62b31ba15d6).

Therefore you lose nothing for which you already paid since practically KMS first became available.

The size of the kernel binary will indeed grow. Some parts of the DRM framework will have to be linked in. We have been working to further modularize DRM to improve the binary size. It only affects the booting, as the DRM modules are already part of the running system today.

I have machines with a /boot partition that is now insufficient when doing updates to hold the three kernels needed momentarily (previous kernel, running kernel, and new kernel being installed). What size of /boot will now be needed? -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On 24/12/2021 11.18, dieter wrote:

On Fri, 24 Dec 2021 10:37:16 +0100 Carlos E. R. wrote:

...

I have machines with a /boot partition that is now insufficient when doing updates to hold the three kernels needed momentarily (previous kernel, running kernel, and new kernel being installed).

For the issue that more space in a separate /boot filesystem is needed exists bugzilla #1171006.

Sure, that 200M is needed on 15.2, that is not news to me. The machine I'm thinking of has 190M, and that was mostly empty at the time the machine was created. The question is, with this DRM change we will need more. How much more? 1 gig? 2 gigs? More? -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

Hi Am 24.12.21 um 12:01 schrieb Jan Engelhardt:

On Friday 2021-12-24 11:58, Carlos E. R. wrote:

...

On 24/12/2021 11.18, dieter wrote:

...

For the issue that more space in a separate /boot filesystem is needed exists bugzilla #1171006.

Sure, that 200M is needed on 15.2, that is not news to me. The machine I'm thinking of has 190M, and that was mostly empty at the time the machine was created.

The question is, with this DRM change we will need more. How much more? 1 gig? 2 gigs? More?

drm.ko is about 1 megabyte uncompressed, so slightly less inside an initramfs.

Yes. drm.ko is ~1 MiB. Plus helper DRM modules. That's maybe 1.5 to 2 MiB within the kernel binary. We're working on reducing this. Keep in mind that you won't need extra userspace in your initramfs. All you need is the kernel code. Best regards Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

On Friday 2021-12-24 19:13, Carlos E. R. wrote:

...

Yes. drm.ko is ~1 MiB. Plus helper DRM modules. That's maybe 1.5 to 2 MiB within the kernel binary. We're working on reducing this. Keep in mind that you won't need extra userspace in your initramfs. All you need is the kernel code.

That's not much, you people had me scared with your talk of "bigger footprint" :-p

Local numbers: kernel 10M in vmlinuz form (83 MB uncompressed) initrd 14M in cpio zstd-9 form (46 MB uncompressed) \_ kernel/device drivers make up 16 of 46 MB Adding another 2M of (uncompressed) code for DRI. Can be much.

Hi Am 24.12.21 um 11:37 schrieb Jogchum Reitsma:

Op 23-12-2021 om 11:00 schreef Thomas Zimmermann:

...

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.

Why switch? The generic DRM driver provides a fallback for all systems without hardware-specific drivers. Even with broken hardware drivers, generic DRM can most likely boot and provide graphics output. This isn't easily possible with fbdev. Fbdev has been out of date for several years. Modern graphics userspace slowly uses the ability to run on top of fbdev. Most notably, wayland compositors are affected by this. We also have received reports about systems being unable to boot because of fbdev.

TW's X11 and userspace should be ready (sans bugs). If you want to test, Takashi provides a kernel that has full-DRM enabled at

https://download.opensuse.org/repositories/home:/tiwai:/simpledrm/

If you install and boot the kernel, you should ideally see no difference. Once booted the hardware's driver will do the graphics output. To test if you booted with generic DRM, do

  dmesg | grep drm

Here, this gives

drm... [    7.933792] [drm] [nvidia-drm] [GPU ID 0x00004100] Loading driver [    8.967538] [drm] Initialized nvidia-drm0.0.0 20160202 for 0000:41:00.0 on minor 0 [269005.669940] [drm:drm_new_set_master [drm]] *ERROR* [nvidia-drm] [GPU ID 0x00004100] Failed to grab modeset ownership

on

Linux linux-mkay 5.15.7-1-default #1 SMP Wed Dec 8 08:54:39 UTC 2021 (b92986a) x86_64 x86_64 x86_64 GNU/Linux

Despite the error mentioned in the last line I encounter no problems with my graphics setup. But I don't have the expertise to know what it means.

That's helpful. Thank you very much. I'm not sure if it's actually related, but we'll investigate the issue. Best regards Thomas

regards, Jogchum

...

on the command line. The output should mention 'simpledrm' somewhere. If you want to run your system with the generic driver only, pass

  nomodeset

on the kernel command line in Grub. The booted system should run with only software rendering, but provide useful output via X11, wayland and console.

We welcome bug reports. If you find issues, please leave a comment in boo#1193250

https://bugzilla.opensuse.org/show_bug.cgi?id=1193250

Best regards Thomas

-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

lø., des. 25 2021 at kl. 21.25 +0100 +0100 skrev Andreas Prittwitz følgende:

On 23/12/2021 11:00, Thomas Zimmermann wrote:

...

tl;dr: Enable DRM for all graphics output and retire fbdev drivers in TW.

If you install and boot the kernel, you should ideally see no difference. Once booted the hardware's driver will do the graphics output. To test if you booted with generic DRM, do

dmesg | grep drm

The boot sequence was smooth as always on my 64-bit TW installation with an AMD RX 5700 XT.

Working just fine here too. $ dmesg | grep drm [ 0.601458] [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0 [ 0.606100] simple-framebuffer simple-framebuffer.0: [drm] drm_plane_enable_fb_damage_clips() not called [ 0.688493] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device [ 6.116323] fbcon: nouveaudrmfb (fb0) is primary device [ 6.116453] nouveau 0000:01:00.0: [drm] fb0: nouveaudrmfb frame buffer device [ 6.130099] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0 [ 7.271035] systemd[1]: Starting Load Kernel Module drm... [ 7.292851] systemd[1]: modprobe@drm.service: Deactivated successfully. [ 7.293077] systemd[1]: Finished Load Kernel Module drm. $ $ inxi -Ga Graphics: Device-1: NVIDIA GK208B [GeForce GT 730] vendor: ZOTAC driver: nouveau v: kernel bus-ID: 01:00.0 chip-ID: 10de:1287 class-ID: 0300 Device-2: Logitech HD Pro Webcam C920 type: USB driver: snd-usb-audio,uvcvideo bus-ID: 3-1.3:4 chip-ID: 046d:082d class-ID: 0102 serial: AF9F82AF Display: wayland server: SUSE LINUX 1.21.1.2 compositor: gnome-shell v: 41.2 driver: loaded: modesetting unloaded: fbdev,vesa alternate: nouveau,nv,nvidia display-ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x286mm (20.0x11.3") s-diag: 583mm (23") Monitor-1: XWAYLAND0 res: 1920x1080 hz: 60 dpi: 102 size: 480x270mm (18.9x10.6") diag: 551mm (21.7") OpenGL: renderer: NV106 v: 4.3 Mesa 21.3.1 direct render: Yes $ /Bjørn

Hi, thanks for all the feedback you sent in. Best regards Thomas Am 26.12.21 um 17:05 schrieb Felix Miata:

Thomas Zimmermann composed on 2021-12-23 11:00 (UTC+0100):

...

TW's X11 and userspace should be ready (sans bugs). If you want to test, Takashi provides a kernel that has full-DRM enabled at

...

https://download.opensuse.org/repositories/home:/tiwai:/simpledrm/

...

If you install and boot the kernel, you should ideally see no difference. Once booted the hardware's driver will do the graphics output. To test if you booted with generic DRM, do

...

dmesg | grep drm

...

on the command line. The output should mention 'simpledrm' somewhere.

Found another hit, but with a problem: it breaks TDM. It takes startx to get an X session open: # zypper se -si nel-def | grep 5.15.1 il | kernel-default | package | 5.15.11-5.1.g730a488 | x86_64 | homeTiwaiSimpledrm # inxi -SGayz System: Kernel: 5.15.11-5.g730a488-default x86_64 bits: 64 compiler: gcc v: 11.2.1 parameters: BOOT_IMAGE=/boot/vmlinuz root=LABEL=pi3p07stw noresume ipv6.disable=1 net.ifnames=0 mitigations=auto 5 Console: pty pts/0 wm: kwin_x11 DM: TDM Distro: openSUSE Tumbleweed 20211224 Graphics: Device-1: Intel HD Graphics 630 vendor: Gigabyte driver: i915 v: kernel bus-ID: 00:02.0 chip-ID: 8086:5912 class-ID: 0300 Display: server: X.org 1.21.1.2 compositor: kwin_x11 driver: loaded: modesetting unloaded: fbdev,vesa alternate: intel Message: Advanced graphics data unavailable for root. # dmesg | grep -i simple [ 0.438182] [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0 [ 0.438950] simple-framebuffer simple-framebuffer.0: [drm] drm_plane_enable_fb_damage_clips() not called [ 0.443365] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device # cat /var/log/tdm.log Dec 26 10:21:12 tdm_config[810] info: Cannot open master configuration file /etc/trinity/tdm/tdmdistrc

X.Org X Server 1.21.1.2 X Protocol Version 11, Revision 0 Current Operating System: Linux gb250 5.15.11-5.g730a488-default #1 SMP Thu Dec 23 06:47:43 UTC 2021 (730a488) x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz root=LABEL=pi3p07stw noresume ipv6.disable=1 net.ifnames=0 mitigations=auto 5

Current version of pixman: 0.40.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sun Dec 26 10:21:12 2021 (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) (EE) Backtrace: (EE) 0: /usr/bin/Xorg.bin (xorg_backtrace+0x85) [0x5600fa3e68e5] (EE) 1: /usr/bin/Xorg.bin (0x5600fa210000+0x1d83e5) [0x5600fa3e83e5] (EE) 2: /lib64/libc.so.6 (0x7fa60c4c1000+0x56430) [0x7fa60c517430] (EE) 3: /lib64/libc.so.6 (0x7fa60c4c1000+0x19ce05) [0x7fa60c65de05] (EE) 4: /usr/bin/Xorg.bin (0x5600fa210000+0xc61ef) [0x5600fa2d61ef] (EE) 5: /usr/bin/Xorg.bin (0x5600fa210000+0xc71c5) [0x5600fa2d71c5] (EE) 6: /usr/bin/Xorg.bin (0x5600fa210000+0xc72d8) [0x5600fa2d72d8] (EE) 7: /usr/bin/Xorg.bin (0x5600fa210000+0x1db5e1) [0x5600fa3eb5e1] (EE) 8: /usr/bin/Xorg.bin (WaitForSomething+0x1e0) [0x5600fa3e5290] (EE) 9: /usr/bin/Xorg.bin (0x5600fa210000+0x4c3b9) [0x5600fa25c3b9] (EE) 10: /lib64/libc.so.6 (0x7fa60c4c1000+0x405c0) [0x7fa60c5015c0] (EE) 11: /lib64/libc.so.6 (__libc_start_main+0x7e) [0x7fa60c50167c] (EE) 12: /usr/bin/Xorg.bin (_start+0x25) [0x5600fa25ce85] (EE) (EE) Segmentation fault at address 0x0 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. (EE) (II) AIGLX: Suspending AIGLX clients for VT switch [tdekbdledsync] Unable to open X11 display! (EE) Server terminated with error (1). Closing log file. [2021/12/26 10:21:14.492] ERROR: cannot connect to X server Dec 26 10:21:14 tdm: :0[1019] error: Abnormal termination of greeter for display :0, code 1, signal 0 #

I sent this and a coredump to http://bugzilla.opensuse.org/show_bug.cgi?id=1193250

-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

On Sun, Feb 06, 2022 at 03:03:43AM -0500, Felix Miata wrote:

Thomas Zimmermann composed on 2022-01-06 09:59 (UTC+0100):

...

thanks for all the feedback you sent in.

You're welcome. Are you looking for any more in particular?

I put Tiwai's simpledrm 5.16.5-7.g8e500f5-default on an old Dell Optiplex GX320 with Radeon Xpress 200/1100 graphics, 2.0GHz Core2Duo and no UEFI. Immediately after Grub (not Grub2) gets the initrd loaded, the screen pauses 30 seconds to report (in 80x25 BIOS mode):

Probing EDD (edd=off to disable)... ok undefined video mode number: 317 Press <ENTER> to see video modes available...

Maybe you can do what asked here, boot in one of the supported modes, and provide kernel log (preferably attach to a bug report) together with a kernel log of the kernel that worked for you.

This doesn't happen with 5.15.12 (newest kernel installed prior to 5.16.5). When it proceeds after the pause, it's in gargantuan text BIOS 80x25 mode for a very long time before KMS finally engages the display's native mode, or the mode specified by video=. Adding edd=off to kernel cmdline is unhelpful. I tried checking other modes available, selecting one (133) before proceeding, which produced some seriously ugly text, though space saving compared to 80x25.

Why is simple DRM preventing use of a standard vesafb mode in the time before KMS engages? Is something else needed in the initrd or on kernel cmdline to enjoy

In most cases it is not.

traditional vesafb modes like vga=0x317 & vga=794 prior to KMS engagement?

If the mode worked previously and now it does not it is a regression in communicating supported modes with the BIOS which may be caused by simpledrm, other kernel changes, BIOS settings, and BIOS changes. It's something worth diagnosing.

Is it possible to get KMS to engage much earlier?

Maybe I need a reminder why simpledrm in the first place? :p

Because the fbdev interface is broken by design and cannot be fixed without breaking all software using it. Then you couuld either create a fbdev 2.0 or declare something else that already exists like drm the fbdev 2.0 Thanks Michal

On 1/29/22 01:37, Thomas Zimmermann wrote:

Hi

...

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

That's unintentionally.

...

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.

Yes, please.

https://bugzilla.suse.com/show_bug.cgi?id=1195297

...

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

That's the driver for the display.

Yep just confirming I took this output before I updated to the current version while the display was still working.

...

[   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

Here we switch drivers for the HDMI output. The TFT should be unaffected.

I tried to update my RPi to the latest Tumbleweed. But I didn't get any output on HDMI. I think something else is broken here.

I used the enlightenment image and it boots fine into enlightenment with X11 on the HDMI port. -- 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

Hello, On Fri, Feb 04, 2022 at 02:07:32PM +0100, Christophe Giboudeaux wrote:

Hello,

On Thursday, 23 December 2021 11:00:00 CET 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.

https://paste.opensuse.org/71188719

Here's how the boot animation appears using kernel 5.16.5-4.g8e500f5-default from Kernel:stable and a NVidia card (driver 470.103.01 is installed)

http://bugzilla.opensuse.org/show_bug.cgi?id=1193250#c23

% dmesg | grep framebuffer [ 0.267474] [drm] Initialized simpledrm 1.0.0 20200625 for simple- framebuffer.0 on minor 0 [ 0.269236] simple-framebuffer simple-framebuffer.0: [drm] drm_plane_enable_fb_damage_clips() not called [ 0.280579] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device

According to this you have two screens and one framebuffer. I suppose with one screen only this would work. What was the behavior previously? Thanks Michal

Hi Am 08.07.22 um 10:15 schrieb Mathias Homann:

Am Freitag, 8. Juli 2022, 09:18:26 CEST schrieb Thomas Zimmermann:

...

Hi,

just a quick note that I re-submitted the config changes to update the graphics stack. Please see my mail below for the rational and details.

To go back to the old config, pass

'nosimplefb'

on the kernel command line. Users of the proprietary Nvidia graphics driver will continue to use the old config for now.

2 questions: will this happen on its own, or will nvidia users have to manually do something to their systems?

Modesetting with Nvidia devices depends on the kernel parameter nvidia-drm.modeset. If the parameter has been given, the kernel will use the old graphics config with fbdev's efifb. We set this by default on TW, so it should work out of the box.

and what about nvidia optimus laptops, i.e. intel graphics as main X11 with rendering offloaded to the nvidia chip if required?

I don't have a system to test this. My understanding is that the Intel chips is the primary display and the Nvidia is not being used for any actual displaying. So it should work as well. If it doesn't, you can go back to the old config by giving nosimplefb on the kernel command line.

and finally, this will just appear in a snapshot sometime soon now?

It's pending. I expect it to be in the next kernel release (5.18.3.* ?). Best regards Thomas

Cheers MH

-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

Hi Am 08.07.22 um 13:01 schrieb Mathias Homann:

Am Freitag, 8. Juli 2022, 10:58:03 CEST schrieb Thomas Zimmermann:

...

Hi

Am 08.07.22 um 10:15 schrieb Mathias Homann:

...

Am Freitag, 8. Juli 2022, 09:18:26 CEST schrieb Thomas Zimmermann:

...

Hi,

just a quick note that I re-submitted the config changes to update the graphics stack. Please see my mail below for the rational and details.

To go back to the old config, pass

'nosimplefb'

on the kernel command line. Users of the proprietary Nvidia graphics driver will continue to use the old config for now.

2 questions: will this happen on its own, or will nvidia users have to manually do something to their systems?

Modesetting with Nvidia devices depends on the kernel parameter nvidia-drm.modeset. If the parameter has been given, the kernel will use the old graphics config with fbdev's efifb. We set this by default on TW, so it should work out of the box.

that's good enough for me ;)

...

...

and what about nvidia optimus laptops, i.e. intel graphics as main X11 with rendering offloaded to the nvidia chip if required?

I don't have a system to test this. My understanding is that the Intel chips is the primary display and the Nvidia is not being used for any actual displaying. So it should work as well.

If it doesn't, you can go back to the old config by giving

nosimplefb

on the kernel command line.

guess I'll keep you updated once it comes around ;)

...

...

and finally, this will just appear in a snapshot sometime soon now? It's pending. I expect it to be in the next kernel release (5.18.3.* ?).

uhm... mathias@mio:~> tumbleweed status latest : 20220706 target : 20220706 installed: 20220706 mathias@mio:~> uname -a Linux mio 5.18.9-1-default #1 SMP PREEMPT_DYNAMIC Sun Jul 3 08:04:03 UTC 2022 (0e67dc1) x86_64 x86_64 x86_64 GNU/Linux

wouldn't that mean it's out already?

Oops, typo. I meant 5.18.9-3 at the earliest. Best regards Thomas

Cheers MH

-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev