Linux graphics on TW: going full-DRM; retiring fbdev drivers
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 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
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?
Hi Am 23.12.21 um 12:35 schrieb Dominique Leuenberger / DimStar:
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?
Oh, well! I should have spelled it out, indeed. It's not about Digital Rights Management. DRM is the Direct Rendering Manager; Linux' infrastructure for graphics output. 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
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
Hi Am 23.12.21 um 13:06 schrieb Konstantin Voinov:
Hi!
Will it work with Nvidia?
Yes. I've successfully tested this with x11-video-gfxG04 and x11-video-gfxG05. We've also added a patch to make it work more reliable on the most recent driver package. 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
On Thu, Dec 23, 2021 at 11:00:00AM +0100, Thomas Zimmermann wrote:
tl;dr: Enable DRM for all graphics output and retire fbdev drivers in TW.
...
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.
Ah, this might explain what I think is a race/missing dependency condition with an as-yet updated Leap 15.2 machine with the prompt to decrypt home disks. Since switching from nouveau to the proprietary nvidia driver the "pretty" prompt doesn't appear in the splash screen during boot, but if I drop out to the boot console I can see a prompt from systemd waiting for the key to decrypt and mount the disk. This might be a very narrow use-case, and/or fixed in 15.3 & TW for a while. And I know the proprietary nvidia driver isn't openSUSE's responsibility (but it doesn't lock the display ~1 in 5 suspend/resume cycles) Daniel
On 12/23/21 04:00, Thomas Zimmermann wrote:
We welcome bug reports. If you find issues, please leave a comment in boo#1193250
No bugs found on my Toshiba laptop with an i915 graphics adapter. I noticed no difference in the boot sequence. Larry
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
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
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
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: <missing: xdpyinfo> 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. Larry
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
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: <missing: xdpyinfo> 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 23/12/2021 11:00, 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.
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
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 I just wonder what this implies for text based output only? Another consequence is that the kernel footprint will be raised again due to the presence of the DRM code. In graphics mode, this is no issue (the footprint remains more or less the same) but in text mode it requires code availability which was not needed before.
Regards, Frans.
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.
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:
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.
That's exactly what the generic DRM driver is about. [1] It's built into the kenel binary and ready as soon as efifb/vesafb would be. The hardware driver still gets loaded later from the initramfs.
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. Best regards Thomas [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv... -- 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 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 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. For all my affected systems the procedure described in https://bugzilla.opensuse.org/show_bug.cgi?id=1171006#c6 (replace /dev/sda1 with your current /boot partition in the command mount /dev/sda1 /mnt) worked. Possibly on EFI systems the /boot/efi filesystem should also be unmounted before unmounting the /boot filesystem. Regards, Dieter
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)
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.
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 24/12/2021 18.20, Thomas Zimmermann wrote:
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.
That's not much, you people had me scared with your talk of "bigger footprint" :-p -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
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.
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. 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
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
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. dmesg | grep drm [ 0.574498] [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0 [ 0.575160] simple-framebuffer simple-framebuffer.0: [drm] drm_plane_enable_fb_damage_clips() not called [ 0.576646] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device [ 2.336927] [drm] amdgpu kernel modesetting enabled. [ 2.381770] [drm] initializing kernel modesetting (NAVI10 0x1002:0x731F 0x148C:0x2398 0xC1). [ 2.381778] [drm] register mmio base: 0xFCD00000 [ 2.381779] [drm] register mmio size: 524288 [ 2.382849] [drm] add ip block number 0 <nv_common> [ 2.382850] [drm] add ip block number 1 <gmc_v10_0> [ 2.382850] [drm] add ip block number 2 <navi10_ih> [ 2.382851] [drm] add ip block number 3 <psp> [ 2.382851] [drm] add ip block number 4 <smu> [ 2.382852] [drm] add ip block number 5 <dm> [ 2.382852] [drm] add ip block number 6 <gfx_v10_0> [ 2.382853] [drm] add ip block number 7 <sdma_v5_0> [ 2.382854] [drm] add ip block number 8 <vcn_v2_0> [ 2.382855] [drm] add ip block number 9 <jpeg_v2_0> [ 2.382872] [drm] VCN decode is enabled in VM mode [ 2.382872] [drm] VCN encode is enabled in VM mode [ 2.382873] [drm] JPEG decode is enabled in VM mode [ 2.382887] [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit [ 2.382899] [drm] Detected VRAM RAM=8176M, BAR=8192M [ 2.382900] [drm] RAM width 256bits GDDR6 [ 2.382929] [drm] amdgpu: 8176M of VRAM memory ready [ 2.382930] [drm] amdgpu: 8176M of GTT memory ready. [ 2.382932] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 2.383037] [drm] PCIE GART of 512M enabled (table at 0x0000008000300000). [ 2.420276] [drm] Found VCN firmware Version ENC: 1.14 DEC: 5 VEP: 0 Revision: 20 [ 2.594166] [drm] reserve 0x900000 from 0x81fe400000 for PSP TMR [ 2.672770] [drm] Display Core initialized with v3.2.149! [ 2.957806] [drm] kiq ring mec 2 pipe 1 q 0 [ 2.959840] [drm] VCN decode and encode initialized successfully(under DPG Mode). [ 2.960230] [drm] JPEG decode initialized successfully. [ 3.011702] [drm] fb mappable at 0xFC00502000 [ 3.011703] [drm] vram apper at 0xFC00000000 [ 3.011703] [drm] size 14745600 [ 3.011704] [drm] fb depth is 24 [ 3.011704] [drm] pitch is 10240 [ 3.011756] fbcon: amdgpudrmfb (fb0) is primary device [ 3.210570] amdgpu 0000:0a:00.0: [drm] fb0: amdgpudrmfb frame buffer device [ 3.234943] [drm] Initialized amdgpu 3.42.0 20150101 for 0000:0a:00.0 on minor 0 [ 3.806290] systemd[1]: Starting Load Kernel Module drm... inxi -Ga Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] vendor: Tul driver: amdgpu v: kernel bus-ID: 0a:00.0 chip-ID: 1002:731f class-ID: 0300 Display: x11 server: X.org 1.21.1.1 compositor: kwin_x11 driver: loaded: amdgpu,ati unloaded: fbdev,modesetting,radeon,vesa resolution: <missing: xdpyinfo> OpenGL: renderer: AMD Radeon RX 5700 XT (NAVI10 DRM 3.42.0 5.15.11-5.g730a488-default LLVM 13.0.0) v: 4.6 Mesa 21.3.1 direct render: Yes -- On a long enough timeline the survival rate for everyone drops to zero...
lø., des. 25 2021 at kl. 21.25 +0100 +0100 skrev Andreas Prittwitz <m4ng4n@gmx.de> 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
Thomas Zimmermann composed on 2021-12-23 11:00 (UTC+0100):
tl;dr: Enable DRM for all graphics output and retire fbdev drivers in TW.
Something's causing XDM/TDM to produce segfaults: https://paste.opensuse.org/20936212 https://paste.opensuse.org/53155693 Xorg & ttys eventually seem OK, but any video at all seems to start only after boot is complete. And, these are not helped: https://gitlab.freedesktop.org/drm/intel/-/issues/4762 http://bugzilla.opensuse.org/show_bug.cgi?id=1193640 # inxi -GSCxxyz System: Kernel: 5.15.11-5.g730a488-default x86_64 bits: 64 compiler: gcc v: 11.2.1 Console: pty pts/1 DM: TDM Distro: openSUSE Tumbleweed 20211224 Machine: Type: Desktop System: ASUS product: N/A v: N/A serial: N/A Mobo: ASUSTeK model: PRIME B560M-A v: Rev 1.xx serial: <filter> UEFI: American Megatrends v: 1203 date: 10/27/2021 CPU: Info: 6-core model: 11th Gen Intel Core i5-11400 bits: 64 type: MT MCP arch: Rocket Lake rev: 1 cache: L1: 480 KiB L2: 3 MiB L3: 12 MiB Speed (MHz): avg: 801 min/max: 800/4400 cores: 1: 801 2: 801 3: 801 4: 801 5: 801 6: 801 7: 801 8: 801 9: 801 10: 801 11: 801 12: 801 bogomips: 62208 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx Graphics: Device-1: Intel RocketLake-S GT1 [UHD Graphics 730] vendor: ASUSTeK driver: i915 v: kernel bus-ID: 00:02.0 chip-ID: 8086:4c8b Display: server: X.org 1.21.1.2 driver: loaded: modesetting unloaded: fbdev,vesa alternate: intel Message: Advanced graphics data unavailable for root. -- 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
Thomas Zimmermann composed on 2021-12-23 11:00 (UTC+0100):
To test if you booted with generic DRM, do
dmesg | grep drm
on the command line. The output should mention 'simpledrm' somewhere.
I'm not sure if what I'm seeing means anything needs fixing: # lsmod | grep simple # lsmod | grep drm drm_ttm_helper 16384 1 nouveau ttm 81920 2 drm_ttm_helper,nouveau # inxi -SGayz System: Kernel: 5.15.11-5.g730a488-default x86_64 bits: 64 compiler: gcc v: 11.2.1 parameters: root=LABEL=sTWp23h8s ipv6.disable=1 net.ifnames=0 noresume mitigations=auto consoleblank=0 5 Desktop: KDE Plasma 5.23.4 tk: Qt 5.15.2 wm: kwin_x11 vt: 7 dm: KDM Distro: openSUSE Tumbleweed 20211224 Graphics: Device-1: NVIDIA GT218 [GeForce 210] vendor: eVga.com. driver: nouveau v: kernel bus-ID: 01:00.0 chip-ID: 10de:0a65 class-ID: 0300 Display: x11 server: X.Org 1.21.1.2 compositor: kwin_x11 driver: loaded: modesetting unloaded: fbdev,vesa alternate: nouveau,nv,nvidia display-ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1200 s-dpi: 120 s-size: 406x254mm (16.0x10.0") s-diag: 479mm (18.9") Monitor-1: DVI-I-1 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8") diag: 612mm (24.1") OpenGL: renderer: llvmpipe (LLVM 13.0.0 128 bits) v: 4.5 Mesa 21.3.1 direct render: Yes # -- 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
Felix Miata composed on 2021-12-26 01:01 (UTC-0500):
Thomas Zimmermann composed on 2021-12-23 11:00 (UTC+0100):
To test if you booted with generic DRM, do
dmesg | grep drm
on the command line. The output should mention 'simpledrm' somewhere.
I'm not sure if what I'm seeing means anything needs fixing: # lsmod | grep simple # lsmod | grep drm drm_ttm_helper 16384 1 nouveau ttm 81920 2 drm_ttm_helper,nouveau
# inxi -Sayz System: Kernel: 5.15.11-5.g730a488-default x86_64 bits: 64 compiler: gcc v: 11.2.1 parameters: root=LABEL=sTWp23h8s ipv6.disable=1 net.ifnames=0 noresume mitigations=auto consoleblank=0 5 Console: pty pts/0 wm: kwin_x11 DM: KDM Distro: openSUSE Tumbleweed 20211224 # dmesg | grep drm [ 14.959050] systemd[1]: Starting Load Kernel Module drm... [ 15.046380] systemd[1]: modprobe@drm.service: Deactivated successfully. [ 15.046609] systemd[1]: Finished Load Kernel Module drm. [ 24.601836] fbcon: nouveaudrmfb (fb0) is primary device [ 24.654720] nouveau 0000:01:00.0: [drm] fb0: nouveaudrmfb frame buffer device [ 24.673921] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0 # dmesg | grep -i simple # zypper se -si nel-def | grep 5.15 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: root=LABEL=sTWp23h8s ipv6.disable=1 net.ifnames=0 noresume mitigations=auto consoleblank=0 5 Desktop: KDE Plasma 5.23.4 tk: Qt 5.15.2 wm: kwin_x11 vt: 7 dm: KDM Distro: openSUSE Tumbleweed 20211224 Graphics: Device-1: NVIDIA GT218 [GeForce 210] vendor: eVga.com. driver: nouveau v: kernel bus-ID: 01:00.0 chip-ID: 10de:0a65 class-ID: 0300 Display: x11 server: X.Org 1.21.1.2 compositor: kwin_x11 driver: loaded: modesetting unloaded: fbdev,vesa alternate: nouveau,nv,nvidia display-ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1200 s-dpi: 120 s-size: 406x254mm (16.0x10.0") s-diag: 479mm (18.9") Monitor-1: DVI-I-1 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8") diag: 612mm (24.1") OpenGL: renderer: llvmpipe (LLVM 13.0.0 128 bits) v: 4.5 Mesa 21.3.1 direct render: Yes # -- 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
Thomas Zimmermann composed on 2021-12-23 11:00 (UTC+0100):
To test if you booted with generic DRM, do
dmesg | grep drm
on the command line. The output should mention 'simpledrm' somewhere.
On old Radeon there's a lot more from lsmod than old NVidia, but no "simple": # lsmod | grep simple # lsmod | grep drm drm_ttm_helper 16384 1 radeon ttm 61440 2 drm_ttm_helper,radeon drm_kms_helper 245760 1 radeon cec 49152 1 drm_kms_helper fb_sys_fops 16384 1 drm_kms_helper syscopyarea 16384 1 drm_kms_helper sysfillrect 16384 1 drm_kms_helper sysimgblt 16384 1 drm_kms_helper drm 450560 10 drm_ttm_helper,radeon,ttm,drm_kms_helper # inxi -SGayz System: Kernel: 5.15.11-5.g730a488-default i686 bits: 32 compiler: gcc v: 11.2.1 parameters: root=LABEL=11ostw ipv6.disable=1 net.ifnames=0 noresume vga=791 video=1024x768@60 video=1440x900@60 5 Desktop: KDE Plasma 5.23.4 tk: Qt 5.15.2 wm: kwin_x11 vt: 7 dm: KDM Distro: openSUSE Tumbleweed 20211224 Graphics: Device-1: AMD RV516 [Radeon X1300/X1550 Series] vendor: Dell driver: radeon v: kernel bus-ID: 01:00.0 chip-ID: 1002:7183 class-ID: 0300 Display: x11 server: X.Org 1.21.1.2 compositor: kwin_x11 driver: loaded: modesetting unloaded: fbdev,vesa alternate: ati display-ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1200 s-dpi: 120 s-size: 406x253mm (16.0x10.0") s-diag: 478mm (18.8") Monitor-1: DVI-I-1 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8") diag: 612mm (24.1") OpenGL: renderer: ATI RV515 v: 2.1 Mesa 21.3.1 direct render: Yes # Almost all seems fine. Ttys and Xorg work, but bad things show up in journal and dmesg: https://paste.opensuse.org/42174599 -- 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
Felix Miata composed on 2021-12-26 04:40 (UTC-0500):
Thomas Zimmermann composed on 2021-12-23 11:00 (UTC+0100):
To test if you booted with generic DRM, do
dmesg | grep drm
on the command line. The output should mention 'simpledrm' somewhere.
On old Radeon there's a lot more from lsmod than old NVidia, but no "simple":
# lsmod | grep simple # lsmod | grep drm drm_ttm_helper 16384 1 radeon ttm 61440 2 drm_ttm_helper,radeon drm_kms_helper 245760 1 radeon cec 49152 1 drm_kms_helper fb_sys_fops 16384 1 drm_kms_helper syscopyarea 16384 1 drm_kms_helper sysfillrect 16384 1 drm_kms_helper sysimgblt 16384 1 drm_kms_helper drm 450560 10 drm_ttm_helper,radeon,ttm,drm_kms_helper # inxi -SGayz System: Kernel: 5.15.11-5.g730a488-default i686 bits: 32 compiler: gcc v: 11.2.1 parameters: root=LABEL=11ostw ipv6.disable=1 net.ifnames=0 noresume vga=791 video=1024x768@60 video=1440x900@60 5 Desktop: KDE Plasma 5.23.4 tk: Qt 5.15.2 wm: kwin_x11 vt: 7 dm: KDM Distro: openSUSE Tumbleweed 20211224 Graphics: Device-1: AMD RV516 [Radeon X1300/X1550 Series] vendor: Dell driver: radeon v: kernel bus-ID: 01:00.0 chip-ID: 1002:7183 class-ID: 0300 Display: x11 server: X.Org 1.21.1.2 compositor: kwin_x11 driver: loaded: modesetting unloaded: fbdev,vesa alternate: ati display-ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1200 s-dpi: 120 s-size: 406x253mm (16.0x10.0") s-diag: 478mm (18.8") Monitor-1: DVI-I-1 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8") diag: 612mm (24.1") OpenGL: renderer: ATI RV515 v: 2.1 Mesa 21.3.1 direct render: Yes #
Almost all seems fine. Ttys and Xorg work, but bad things show up in journal and dmesg: https://paste.opensuse.org/42174599
no simple in dmesg either: # uname -a Linux gx28b 5.15.11-5.g730a488-default #1 SMP Thu Dec 23 06:47:43 UTC 2021 (730a488) i686 i686 i386 GNU/Linux # dmesg | grep drm [ 33.799039] systemd[1]: Starting Load Kernel Module drm... [ 75.421833] [drm] radeon kernel modesetting enabled. [ 75.424814] [drm] initializing kernel modesetting (RV515 0x1002:0x7183 0x1028:0x0302 0x00). [ 75.424992] [drm] Generation 2 PCI interface, using max accessible memory [ 75.425074] [drm] Detected VRAM RAM=256M, BAR=256M [ 75.425084] [drm] RAM width 128bits DDR [ 75.425130] [drm] radeon: 256M of VRAM memory ready [ 75.425139] [drm] radeon: 512M of GTT memory ready. [ 75.425156] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 75.428802] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [ 75.432148] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). [ 75.432510] [drm] radeon: irq initialized. [ 75.432533] [drm] Loading R500 Microcode [ 75.989505] [drm] radeon: ring at 0x0000000010001000 [ 75.989559] [drm] ring test succeeded in 7 usecs [ 75.989652] [drm] ib test succeeded in 0 usecs [ 75.992254] [drm] Radeon Display Connectors [ 75.992270] [drm] Connector 0: [ 75.992276] [drm] DVI-I-1 [ 75.992282] [drm] HPD1 [ 75.992287] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [ 75.992298] [drm] Encoders: [ 75.992303] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 75.992309] [drm] DFP1: INTERNAL_KLDSCP_TMDS1 [ 75.992315] [drm] Connector 1: [ 75.992320] [drm] SVIDEO-1 [ 75.992326] [drm] Encoders: [ 75.992331] [drm] TV1: INTERNAL_KLDSCP_DAC2 [ 75.992336] [drm] Connector 2: [ 75.992342] [drm] VGA-1 [ 75.992347] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [ 75.992357] [drm] Encoders: [ 75.992361] [drm] CRT2: INTERNAL_KLDSCP_DAC2 [ 76.120643] [drm] fb mappable at 0xC00C0000 [ 76.120664] [drm] vram apper at 0xC0000000 [ 76.120671] [drm] size 9216000 [ 76.120677] [drm] fb depth is 24 [ 76.120683] [drm] pitch is 7680 [ 76.121351] fbcon: radeondrmfb (fb0) is primary device [ 76.173133] radeon 0000:01:00.0: [drm] fb0: radeondrmfb frame buffer device [ 76.173234] [drm] Initialized radeon 2.50.0 20080528 for 0000:01:00.0 on minor 0 # dmesg | grep imple [ 0.179060] rcu: Hierarchical RCU implementation. [ 0.368862] rcu: Hierarchical SRCU implementation. [ 0.370195] Simple Boot Flag at 0x7a set to 0x1 # zypsei nel-def il | kernel-default | package | 5.12.13-1.1 | i586 | (System Packages) il | kernel-default | package | 5.13.12-1.2 | i586 | (System Packages) il | kernel-default | package | 5.14.14-3.3 | i586 | (System Packages) il | kernel-default | package | 5.15.11-5.1.g730a488 | i586 | homeTiwaiSimpledrm # -- 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
Thomas Zimmermann composed on 2021-12-23 11:00 (UTC+0100):
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.
Another without "simple" in dmesg: # inxi -SGayz System: Kernel: 5.15.11-5.g730a488-default x86_64 bits: 64 compiler: gcc v: 11.2.1 parameters: root=LABEL=ostwK4h50 ipv6.disable=1 net.ifnames=0 noresume mitigations=auto consoleblank=0 vga=791 5 Console: pty pts/0 DM: KDM Distro: openSUSE Tumbleweed 20211224 Graphics: Device-1: NVIDIA GF119 [NVS 310] vendor: Hewlett-Packard driver: nouveau v: kernel bus-ID: 01:00.0 chip-ID: 10de:107d class-ID: 0300 Display: server: X.org 1.21.1.2 driver: loaded: modesetting unloaded: fbdev,vesa alternate: nouveau,nv,nvidia Message: Advanced graphics data unavailable for root. # dmesg | grep -i simple # dmesg | grep -i drm [ 19.519379] systemd[1]: Starting Load Kernel Module drm... [ 19.752729] systemd[1]: modprobe@drm.service: Deactivated successfully. [ 19.752893] systemd[1]: Finished Load Kernel Module drm. [ 28.503648] nouveau 0000:01:00.0: DRM: VRAM: 512 MiB [ 28.503655] nouveau 0000:01:00.0: DRM: GART: 1048576 MiB [ 28.503660] nouveau 0000:01:00.0: DRM: TMDS table version 2.0 [ 28.503663] nouveau 0000:01:00.0: DRM: DCB version 4.0 [ 28.503666] nouveau 0000:01:00.0: DRM: DCB outp 00: 020003a6 0f220010 [ 28.503670] nouveau 0000:01:00.0: DRM: DCB outp 01: 02000362 00020010 [ 28.503674] nouveau 0000:01:00.0: DRM: DCB outp 02: 048113b6 0f220010 [ 28.503677] nouveau 0000:01:00.0: DRM: DCB outp 03: 04011372 00020010 [ 28.503681] nouveau 0000:01:00.0: DRM: DCB conn 00: 00410146 [ 28.503684] nouveau 0000:01:00.0: DRM: DCB conn 01: 00820246 [ 28.504749] nouveau 0000:01:00.0: DRM: MM: using COPY0 for buffer copies [ 28.556360] nouveau 0000:01:00.0: DRM: allocated 2560x1440 fb: 0x60000, bo 000000001481367f [ 28.557974] fbcon: nouveaudrmfb (fb0) is primary device [ 28.670706] nouveau 0000:01:00.0: [drm] fb0: nouveaudrmfb frame buffer device [ 28.684343] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0 # 0_0 -- 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
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.
Again nada for 'simpledrm' on radeon: # inxi -SGayz System: Kernel: 5.15.11-5.g730a488-default x86_64 bits: 64 compiler: gcc v: 11.2.1 parameters: root=/dev/sda10 noresume mitigations=auto consoleblank=0 net.ifnames=0 ipv6.disable=1 5 Console: pty pts/0 wm: Twin DM: TDM Distro: openSUSE Tumbleweed 20211224 Graphics: Device-1: AMD Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] vendor: Dell driver: radeon v: kernel bus-ID: 01:00.0 chip-ID: 1002:6779 class-ID: 0300 Display: server: X.org 1.21.1.2 driver: loaded: modesetting unloaded: fbdev,vesa alternate: ati Message: Advanced graphics data unavailable for root. # dmesg | grep -i simple [ 0.387699] Simple Boot Flag at 0x7a set to 0x80 # dmesg | grep -i drm [ 3.898146] systemd[1]: Starting Load Kernel Module drm... [ 3.925283] systemd[1]: modprobe@drm.service: Deactivated successfully. [ 3.925456] systemd[1]: Finished Load Kernel Module drm. [ 4.853398] [drm] radeon kernel modesetting enabled. [ 4.882234] [drm] initializing kernel modesetting (CAICOS 0x1002:0x6779 0x1028:0x2120 0x00). [ 4.882808] [drm] Detected VRAM RAM=1024M, BAR=256M [ 4.882809] [drm] RAM width 64bits DDR [ 4.882835] [drm] radeon: 1024M of VRAM memory ready [ 4.882837] [drm] radeon: 1024M of GTT memory ready. [ 4.882847] [drm] Loading CAICOS Microcode [ 4.891050] [drm] Internal thermal controller with fan control [ 4.900760] [drm] radeon: dpm initialized [ 4.993120] [drm] GART: num cpu pages 262144, num gpu pages 262144 [ 4.994006] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 5.030259] [drm] PCIE GART of 1024M enabled (table at 0x0000000000162000). [ 5.082680] [drm] radeon: irq initialized. [ 5.150698] [drm] ring test on 0 succeeded in 2 usecs [ 5.150710] [drm] ring test on 3 succeeded in 6 usecs [ 5.450686] [drm] ring test on 5 succeeded in 2 usecs [ 5.450704] [drm] UVD initialized successfully. [ 5.451628] [drm] ib test on ring 0 succeeded in 0 usecs [ 5.451708] [drm] ib test on ring 3 succeeded in 0 usecs [ 6.102620] [drm] ib test on ring 5 succeeded [ 6.103015] [drm] Radeon Display Connectors [ 6.103016] [drm] Connector 0: [ 6.103017] [drm] DP-1 [ 6.103018] [drm] HPD2 [ 6.103018] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [ 6.103020] [drm] Encoders: [ 6.103021] [drm] DFP1: INTERNAL_UNIPHY1 [ 6.103022] [drm] Connector 1: [ 6.103023] [drm] DVI-I-1 [ 6.103024] [drm] HPD4 [ 6.103024] [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c [ 6.103026] [drm] Encoders: [ 6.103026] [drm] DFP2: INTERNAL_UNIPHY [ 6.103027] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 6.156724] [drm] fb mappable at 0xE0363000 [ 6.156726] [drm] vram apper at 0xE0000000 [ 6.156727] [drm] size 9216000 [ 6.156728] [drm] fb depth is 24 [ 6.156729] [drm] pitch is 7680 [ 6.156772] fbcon: radeondrmfb (fb0) is primary device [ 6.317544] radeon 0000:01:00.0: [drm] fb0: radeondrmfb frame buffer device [ 6.330632] [drm] Initialized radeon 2.50.0 20080528 for 0000:01:00.0 on minor 0 # zypper se -si nel-def | grep 5.15.11 il | kernel-default | package | 5.15.11-5.1.g730a488 | x86_64 | homeTiwaiSimpledrm # -- 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
Thomas Zimmermann composed on 2021-12-23 11:00 (UTC+0100):
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.
Yay!!! I found a simpledrm!!! # 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=tvgp07stw noresume ipv6.disable=1 net.ifnames=0 mitigations=auto consoleblank=0 radeon.cik_support=0 amdgpu.cik_support=1 5 Console: pty pts/0 wm: Twin DM: TDM Distro: openSUSE Tumbleweed 20211224 Graphics: Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK driver: amdgpu v: kernel alternate: radeon bus-ID: 00:01.0 chip-ID: 1002:130f class-ID: 0300 Display: server: X.org 1.21.1.2 driver: loaded: amdgpu unloaded: fbdev,modesetting,vesa alternate: ati Message: Advanced graphics data unavailable for root. # dmesg | grep -i simple [ 0.612987] [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0 [ 0.615072] simple-framebuffer simple-framebuffer.0: [drm] drm_plane_enable_fb_damage_clips() not called [ 0.625253] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device # hostname asa88 # -- 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
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 -- 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, 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
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... <list of 80 column modes F00-F07> 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 traditional vesafb modes like vga=0x317 & vga=794 prior to KMS engagement? Is it possible to get KMS to engage much earlier? Maybe I need a reminder why simpledrm in the first place? :p -- 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
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... <list of 80 column modes F00-F07>
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
Hi Am 23.12.21 um 11:00 schrieb Thomas Zimmermann:
tl;dr: Enable DRM for all graphics output and retire fbdev drivers in TW.
I sent this mail a while ago. This is just a Thank You to everyone who responded and/or tested on their systems. Luckily, we didn't hear a lot about problems. There's still boo#1193250 https://bugzilla.opensuse.org/show_bug.cgi?id=1193250 if you want to report anything. Best regards Thomas
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
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
On Thu, 2021-12-23 at 11:00 +0100, Thomas Zimmermann wrote:
tl;dr: Enable DRM for all graphics output and retire fbdev drivers in TW.
Quoting Alex Deucher regarding relatively high idle power consumption of GPUs on Linux vs Windows: "That explains it. Windows is able to power off the dGPU when it's not in use, but in Linux, due to the limitations of the framebuffer console, we can't power down the primary GPU right now when the console is bound to it. As a workaround, you can unbind console from the fb or disable the drm fbdev emulation in your kernel config." (source: https://gitlab.freedesktop.org/drm/amd/-/issues/1675) I'm wondering if going full DRM will help solve this issue? Regards, Olav
Hi Am 21.01.22 um 17:50 schrieb Olav Reinert:
On Thu, 2021-12-23 at 11:00 +0100, Thomas Zimmermann wrote:
tl;dr: Enable DRM for all graphics output and retire fbdev drivers in TW.
Quoting Alex Deucher regarding relatively high idle power consumption of GPUs on Linux vs Windows:
"That explains it. Windows is able to power off the dGPU when it's not in use, but in Linux, due to the limitations of the framebuffer console, we can't power down the primary GPU right now when the console is bound to it. As a workaround, you can unbind console from the fb or disable the drm fbdev emulation in your kernel config."
(source: https://gitlab.freedesktop.org/drm/amd/-/issues/1675)
I'm wondering if going full DRM will help solve this issue?
No, not yet. I'm sorry. Replacing the current fb console by something modern is another big project for next year. At least a fully DRM'd graphics stack is a step in this direction. Best regards Thomas
Regards, Olav
-- 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, 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
Hi Am 27.01.22 um 04:17 schrieb Simon Lees:
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.
Thanks for testing.
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
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.
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.
[ 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. Best regards Thomas
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
-- 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 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 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) % 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
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
On Sunday, 6 February 2022 13:02:07 CET Michal Suchánek wrote:
Hello,
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?
With kernel 5.15.12, the boot animation is displayed correctly on both monitors.
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. Please report bugs. Best regards Thomas Am 23.12.21 um 11:00 schrieb 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 looses 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
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
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? and what about nvidia optimus laptops, i.e. intel graphics as main X11 with rendering offloaded to the nvidia chip if required? and finally, this will just appear in a snapshot sometime soon now? Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech Matrix: @mathias:eregion.de IRC: [Lemmy] on liberachat and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
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
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? Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech Matrix: @mathias:eregion.de IRC: [Lemmy] on liberachat and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
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
participants (19)
-
Andreas Prittwitz -
Axel Braun -
Bjørn Lie -
Carlos E. R. -
Christophe Giboudeaux -
Daniel Morris -
dieter -
Dominique Leuenberger / DimStar -
Felix Miata -
Frans de Boer -
Jan Engelhardt -
Jogchum Reitsma -
Konstantin Voinov -
Larry Finger -
Mathias Homann -
Michal Suchánek -
Olav Reinert -
Simon Lees -
Thomas Zimmermann