Migrate from fbdev drivers to simpledrm and DRM fbdev emulation layer

[Timo Aaltonen]

[ Impact ]

The fbdev subsystem has been deprecated for a long time. We should drop it in favour of using simpledrm with fbdev emulation layer.

This requires Kernel config changes:

FB_EFI=n
FB_VESA=n

fbcon will still require FB to be available, but will use the fbdev emulation layer

[ Test Plan ]

* Ensure that systems currently relying on fbdev (and therefore only allowing Xorg logins) such as some virtual machine types, boot with working Wayland support.

[ Where Problems could occur ]

* When this stack is enabled, it changes boot timing such that some drivers may take a longer time to boot and GDM may hang in a black screen (bug 2039757).
* Race conditions could be exposed to DE environments
* Software that expects to find DRM device at /dev/dri/card0 may have a problem.
* Some older versions of NVIDIA driver might not work properly.

[ Other Info ]

* Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=2022385

[bcotton (bcotton-redhat-bugs)]

This is a tracking bug for Change: Replace the fbdev drivers with simpledrm and the DRM fbdev emulation layer
For more details, see: https://fedoraproject.org/wiki/Changes/ReplaceFbdevDrivers

This change replaces the legacy Linux frame buffer device (fbdev) drivers that are still used in Fedora, with the latest simpledrm driver and the DRM fbdev emulation layer.

If you encounter a bug related to this Change, please do not comment here. Instead create a new bug and set it to block this bug.

[fmartine (fmartine-redhat-bugs)]

This change has been present in the Fedora kernel since https://gitlab.com/cki-project/kernel-ark/-/commit/53d2c01aef5aaad8b8bb54e4254f6ae671c76ee5

[fmartine (fmartine-redhat-bugs)]

*** Bug 1986222 has been marked as a duplicate of this bug. ***

[bcotton (bcotton-redhat-bugs)]

This bug appears to have been reported against 'rawhide' during the Fedora Linux 36 development cycle.
Changing version to 36.

[bcotton (bcotton-redhat-bugs)]

We have reached the 'Change complete (100% complete)' deadline in the Fedora Linux 36 release schedule.

At this time, all Changes should be fully complete. Indicate this by setting this tracking bug to ON_QA.

If you need to defer this Change to a subsequent release, please needinfo me.

[bcotton (bcotton-redhat-bugs)]

F36 was released today. If this Change did not land in the release, please notify bcotton as soon as possible.

[Mario Limonciello (superm1)]

I'm adding a task for gdm to this bug. The reason is that if simpledrm is used, we've found race conditions that occur where the transition from simpledrm to the proper KMS driver may race with gdm starting up the login screen.

When gdm loses the race you end up with a black screen. So please make sure that any kernels that do adopt simpledrm the matching GDM for OS releases that run this kernel (think about HWE!) will need to pick up this GDM fix as well.

https://gitlab.gnome.org/GNOME/gdm/-/commit/04e119c8332a564cfad05dfb9cb6ec547d5ba954

[Timo Aaltonen (tjaalton)]

thanks for the heads-up, yeah that'd need to be fixed in jammy as well (for gdm) when a hwe kernel supports simpledrm

I'm thinking if mantic 6.5 would be the first candidate

[Timo Aaltonen (tjaalton)]

all current nvidia releases support simpledrm since last March, except 390 which has been EOL for some time now

[Mario Limonciello (superm1)]

Mantic has 45~beta-1ubuntu1 which picks up the fix for this. Jammy is still open.

[Mario Limonciello (superm1)]

I've uploaded the jammy backport of this patch into the queue, so assigning it to myself. As I have readily seen this problem on my own test kernels I'll validate it with a local kernel with the matching kconfig options when it's accepted. This can then be done in advance of waiting for matching changes landing in OEM-6.5, or HWE-6.5.

[Daniel van Vugt (vanvugt)]

This seems like a significant enhancement that will affect the graphics backends chosen by Plymouth and some desktop sessions, particularly virtual machines. Surely this needs a feature freeze exception?

[Mario Limonciello (superm1)]

The kernel part yes. The bug fix in GDM to prepare for whenever the kernel part happens I would think not.

[Daniel van Vugt (vanvugt)]

Yes I was referring to the linux task.

[Timo Aaltonen (tjaalton)]

Right, I don't think we'll get this in mantic yet, I'll send it for linux-unstable first (and then it'll get enabled by mainline builds).

[Timo Aaltonen (tjaalton)]

can't target NN yet, so it'll stay open for mantic for now

[Steve Langasek (vorlon)]

This has been marked as fixed in mantic, but this bug does not say what the plan is for lunar, which is still the supported upgrade path from jammy.

[Mario Limonciello (superm1)]

The issue won't occur in Lunar. It's only specifically a problem with gdm when a kernel has been configured this way.
It's not a problem in Jammy yet, but will be a problem when such a kernel gets backported as HWE.

[Daniel van Vugt (vanvugt)]

I don't quite follow why we're calling this an issue. It's an enhancement that should target 24.04 only.

[Mario Limonciello (superm1)]

The problem is specifically when 24.04's kernel backports to 22.04 it will expose the race condition to GDM. If that kernel will never backport then it won't be a problem.

[Robie Basak (racb)]

> it will expose the race condition to GDM

What race condition, please? If this is the justification for the proposed SRU, then I'd expect to see that explained, but I don't see any explanation.

[Robie Basak (racb)]

Oh, this?

> When this stack is enabled, it changes boot timing such that some drivers may take a longer time to boot and GDM may hang in a black screen.

In that case, why can you not revert the kernel config change in the HWE backport to Jammy?

[Robie Basak (racb)]

Oh, wait. You are just fixing the race condition?

Please the SRU documentation then. Right now I read "We should drop it in favour of using simpledrm with fbdev emulation layer" which is very misleading as to what you're actually proposing to do.

[Mario Limonciello (superm1)]

> Oh, wait. You are just fixing the race condition?

Yeah; I see the confusion. This issue got caught up by making sure the GDM race condition was fixed at the same as when this feature is enabled.

Perhaps it's better to split the GDM part of it off to it's own bug instead then.

> In that case, why can you not revert the kernel config change in the HWE backport to Jammy?

That's certainly a possible solution, but what happens when people run mainline kernels for testing another issue and are exposed to this? That's how I discovered it, reported it upstream and got it fixed in GDM. It's a trivial fix.

[Daniel van Vugt (vanvugt)]

The GDM issue sounds like something we do want fixed, but not here. It should get its own bug.

This bug should involve no SRUs.

[Mario Limonciello (superm1)]

I've split up the GDM for Jammy change into https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/2039757

[Mario Limonciello (superm1)]

Is this going to happen for noble? It should just be kernel config changes at this point.

[Daniel van Vugt (vanvugt)]

> This requires Kernel config changes:
>
> FB_EFI=n
> FB_VESA=n

I'm testing this and it's a step backwards. The screen just turns black for the first 6 seconds or so while Plymouth waits for i915drmfb to start instead (might be Plymouth's fault for being too picky?). FB_EFI was better because it at least put the BIOS logo on the screen.

[Daniel van Vugt (vanvugt)]

OK I've got simpledrm working now. It needed:

  FB_EFI=n
  FB_VESA=n
  CONFIG_SYSFB_SIMPLEFB=y
  CONFIG_DRM_SIMPLEDRM=y

So now I have working graphics very early:

[ 0.588237] [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0
...
[ 7.153876] [drm] Initialized i915 1.6.0 20230929 for 0000:00:02.0 on minor 1

But this doesn't seem to solve bug 1970069, just reintroduced it on simpledrm instead of efifb:

[ 1.959016] fbcon: Taking over console

[Daniel van Vugt (vanvugt)]

Also to prevent Grub from blanking the screen you need to uncomment:

  GRUB_TERMINAL=console

Then you get a smooth transition from BIOS to kernel graphics (simpledrm). But bug 1970069 still pops up after that.

[Timo Aaltonen (tjaalton)]

Thanks for testing, so DRM_SIMPLEDRM needs to be built-in for it to work properly? I guess that's fine then..

[Mario Limonciello (superm1)]

> Also to prevent Grub from blanking the screen you need to uncomment:

Can you open another bug against GRUB to fix this default for Noble?

> Thanks for testing, so DRM_SIMPLEDRM needs to be built-in for it to work properly

Yeah it should need to be built in.

> But bug 1970069 still pops up after that.

Too bad; but it sounds like between simpledrm, the GRUB policy change and your fbcon patch it would be a great experience!

[Daniel van Vugt (vanvugt)]

False alarm. The screen blanking that GRUB_TERMINAL=console "fixes" was actually caused by me using GRUB_TIMEOUT=3. Changing it back to the default GRUB_TIMEOUT=0 also prevents the blanking mentioned in comment #30.

[Daniel van Vugt (vanvugt)]

I'm told this is in 6.8, and see 6.8 is in proposed.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 6.8.0-11.11

---------------
linux (6.8.0-11.11) noble; urgency=medium

  * noble/linux: 6.8.0-11.11 -proposed tracker (LP: #2053094)

  * Miscellaneous Ubuntu changes
    - [Packaging] riscv64: disable building unnecessary binary debs

 -- Paolo Pisati <email address hidden> Wed, 14 Feb 2024 00:04:31 +0100

[Daniel van Vugt (vanvugt)]

Turns out we didn't even need to modify the kernel for this. By choosing simplefb and the 'tiny' DRM drivers for initrd, we get simpledrm.ko as it existed in our older kernels...

https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462482