Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

tachtler · 2025-06-19 10:27:52

Hello everyone,

I have seen with the command:

# zgrep CONFIG_DRM_SIMPLEDRM /proc/config.gz
CONFIG_DRM_SIMPLEDRM=y

I saw that this value is set to "y" (YES). My question is whether "m"(MODULE) could be set here.

The background is that I would like to run GDM/GNOME under Wayland on a server with Matrox G200 and would like to blacklist the simpledrm kernel module in order to load only the mgag200 driver for the DRM.

dmesg | grep drm
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-linux-lts root=/dev/mapper/pml123-root rw rootflags=subvol=@root loglevel=3 net.ifnames=0 mgag200.modeset=1 video=simpledrm:off
[    0.270559] Kernel command line: BOOT_IMAGE=/vmlinuz-linux-lts root=/dev/mapper/pml123-root rw rootflags=subvol=@root loglevel=3 net.ifnames=0 mgag200.modeset=1 video=simpledrm:off
[    1.533658] ACPI: bus type drm_connector registered
[    1.631157] simple-framebuffer simple-framebuffer.0: [drm] Registered 1 planes with drm panic
[    1.631161] [drm] Initialized simpledrm 1.0.0 for simple-framebuffer.0 on minor 0
[    1.632867] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device
[    3.867842] mgag200 0000:03:00.0: [drm] Registered 1 planes with drm panic
[    3.867847] [drm] Initialized mgag200 1.0.0 for 0000:03:00.0 on minor 0
[    3.873349] fbcon: mgag200drmfb (fb0) is primary device
[    3.961693] mgag200 0000:03:00.0: [drm] fb0: mgag200drmfb frame buffer device
[    7.223946] systemd[1]: Starting Load Kernel Module drm...
[    7.245698] systemd[1]: modprobe@drm.service: Deactivated successfully.
[    7.245926] systemd[1]: Finished Load Kernel Module drm.

Thank you and best regards
Klaus.

ntb314 · 2025-06-19 10:42:21

Hi Klaus,

As far as I understand, since CONFIG_DRM_SIMPLEDRM=y is set in the kernel config, it’s built-in and can’t be blacklisted like a module. I think Arch does this to ensure there's always some basic framebuffer available during early boot.

Your kernel parameters like video=simpledrm:off seem correct, but from what I’ve seen, simpledrm still tends to initialize if it detects a framebuffer from EFI or BIOS. That might explain why it's showing up despite the parameter.

If you want to prevent it from loading, maybe recompiling the kernel with CONFIG_DRM_SIMPLEDRM=m would help, but I haven’t tried that myself.

Hope that helps you somehow!

Cheers!

V1del · 2025-06-19 11:01:28

There's a hack built into the arch kernels because this can give you trouble on nvidia gpus, if you set

nvidia-drm.modeset=1

on your kernel cmdline (the fact that you might not have an nvidia gpu nor the relevant kernel modules installed is irrelevant) that will disable the simpledrm device as well.

Last edited by V1del (2025-06-19 11:03:33)

stronnag · 2025-06-19 11:18:21

You might try this kernel command line option:

initcall_blacklist=simpledrm_platform_driver_init

latalante1 · 2025-06-19 11:19:42

V1del wrote:

There's a hack built into the arch kernels because this can give you trouble on nvidia gpus, if you set
nvidia-drm.modeset=1
on your kernel cmdline (the fact that you might not have an nvidia gpu nor the relevant kernel modules installed is irrelevant) that will disable the simpledrm device as well.

The closed source nvidia external module has never been, is not, and probably will not be part of the linux kernel for a long time.

tachtler · 2025-06-19 11:23:00

V1del wrote:

There's a hack built into the arch kernels because this can give you trouble on nvidia gpus, if you set
nvidia-drm.modeset=1
on your kernel cmdline (the fact that you might not have an nvidia gpu nor the relevant kernel modules installed is irrelevant) that will disable the simpledrm device as well.

Hello V1del,

that sounds like a really wicked hack. I'll try it out later and report back.

Thanks and best regards
Klaus

tachtler · 2025-06-19 11:24:59

stronnag wrote:

You might try this kernel command line option:
initcall_blacklist=simpledrm_platform_driver_init

Hi stronnag,

I'll try it out later, as another option and report back.

Thanks and best regards
Klaus

tachtler · 2025-06-19 11:30:17

ntb314 wrote:

...
If you want to prevent it from loading, maybe recompiling the kernel with CONFIG_DRM_SIMPLEDRM=m would help, but I haven’t tried that myself.

Hi ntb314,

I would like to avoid compiling my own kernel, but thank you for your answer.

Thanks and best regards
Klaus

V1del · 2025-06-19 11:55:56

@latalante1 -- and I never implied otherwise. But that hack exists in all kernels packaged for Arch. https://gitlab.archlinux.org/archlinux/ … type=heads

Afaik there have been some reports of the initcall_blacklist variant to not be as reliable/triggering too late and/or the function name changing between kernels, but it is another option.

tekstryder · 2025-06-19 13:43:39

FYI... I've suggested that the simpledrm-suppressing patch be dropped from Arch and the kernel maintainer is eager to do so.

See here:

• https://gitlab.archlinux.org/archlinux/ … ote_277488

I build with CONFIG_SYSFB_SIMPLEFB is not set. You can leave CONFIG_DRM_SIMPLEDRM=y.

Currently the overstayed-its-welcome patch (while it lasts) is the best option if you need to avoid cooking a custom kernel.

seth · 2025-06-19 17:17:29

You therefore also might want to explore "initcall_blacklist=simpledrm_platform_driver_init" which is not part of any hack, but might intercept too late™ in this case.
@Videl, if they alter the function name, I'm simply gonna look up the new init function name

Fwwi, CONFIG_DRM_SIMPLEDRM=m is rather pointless since the whole point of the driver is to be loaded ahead of everything else and then get replaced by other drivers as their modules get loaded.

That being said: I don't like the idea there not being *some* toggle for that thing because for the most part, i only gets in the way.
That toggle being a historically motivated side-effect of an OOT module is obviously not a very clean solution and turning it into a "nofuckingsimplydumbdevice" parameter would be totally fine by me

tachtler · 2025-06-19 19:49:23

stronnag wrote:

You might try this kernel command line option:
initcall_blacklist=simpledrm_platform_driver_init

Hi stronnag,

it works, as you can see.

dmesg | grep drm
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-linux-lts root=/dev/mapper/pml123-root rw rootflags=subvol=@root loglevel=3 net.ifnames=0 initcall_blacklist=simpledrm_platform_driver_init mgag200.modeset=1
[    0.270927] Kernel command line: BOOT_IMAGE=/vmlinuz-linux-lts root=/dev/mapper/pml123-root rw rootflags=subvol=@root loglevel=3 net.ifnames=0 initcall_blacklist=simpledrm_platform_driver_init mgag200.modeset=1
[    0.271026] blacklisting initcall simpledrm_platform_driver_init
[    1.533391] ACPI: bus type drm_connector registered
[    1.535327] initcall simpledrm_platform_driver_init blacklisted
[    3.243539] mgag200 0000:03:00.0: [drm] Registered 1 planes with drm panic
[    3.243542] [drm] Initialized mgag200 1.0.0 for 0000:03:00.0 on minor 0
[    3.248647] fbcon: mgag200drmfb (fb0) is primary device
[    3.327055] mgag200 0000:03:00.0: [drm] fb0: mgag200drmfb frame buffer device
[    7.396852] systemd[1]: Starting Load Kernel Module drm...
[    7.531120] systemd[1]: modprobe@drm.service: Deactivated successfully.
[    7.531348] systemd[1]: Finished Load Kernel Module drm.

Unfortunately, the effect I had hoped for, that I could create a DRM renderer under /dev/dri/renderD128 with the mgag200 driver and the kernel parameter mgag200.modeset=1, did not materialize.

Nevertheless, many thanks for your support, I will probably have to continue tinkering.

Greetings
Klaus.

ddd · 2026-03-27 20:58:57

Did anyone manage to get rid of simpledrm/simplefb now with the patch gone? Blacklisting simpledrm_platform_driver_init and sysfb_init does not work. This makes the first/only gpu card1, not card0 and breaks stuff such as spice-vdagent. I find it incredibly annoying that I cannot get rid of this anymore. According to initcall_debug, the initcall_blacklist=sysfb_init is just completely ignored and called anyway.

Last edited by ddd (2026-03-27 21:10:58)

seth · 2026-03-27 21:10:05

breaks stuff such as spice-vdagent

How exactly?
(You'll currently not be able to block this thing w/o building a custom kernel)

ddd · 2026-03-27 21:14:24

seth wrote:

breaks stuff such as spice-vdagent
How exactly?
(You'll currently not be able to block this thing w/o building a custom kernel)

Well, that just sucks. It breaks it by naming the GPU card1, not card0, which is a known sideeffect of this. There are ways around it by configuring spice-vdagent, but it's annoying when running Live Arch/Arch-based distros (adding kernel parameters is relatively easy). Also, this tends to break some GPU passthrough setups.

EDIT: Well, blacklisting sysfb_init actually seems to work in 6.18/LTS (and results in fbcon using virtio_gpudrmfb, as it should), but not in 6.19! Is this a known thing, or a regression?

Last edited by ddd (2026-03-27 21:41:51)

seth · 2026-03-27 21:50:20

https://elixir.bootlin.com/linux/v6.19. … sfb.c#L224 is still there and hasn't changed
Sure it's the kernel version and not a lack of virtio_gpudrmfb or a race condition (pot. initramfs presence driven)?

ddd · 2026-03-27 23:42:42

Sorry, my bad. Turns out, blacklisting (initcall_blacklist=sysfb_init) works just fine on Arch 6.19 kernel. It does not work only in CachyOS kernel 6.19 (while in CachyOS LTS kernel 6.18 blacklisting still works). Sorry for the mixup, I must have made a typo or something when testing the Arch kernel.

Also: It turns out, that the problem with spice-vdagent and resizing guest to match windows size was also caused by something else.

I still wonder what change in CachyOS 6.19 kernel caused the loss of initcall blacklisting functionality (many changes in their 6.19, also compiled in Clang and not GCC), but that does not belong to this forum...

Last edited by ddd (2026-03-27 23:48:16)

seth · 2026-03-28 07:16:13

If you're building linux-cachyos from the AUR anyway, see https://aur.archlinux.org/cgit/aur.git/ … hyos#n7259

tekstryder · 2026-03-28 17:09:07

ddd wrote:

Did anyone manage to get rid of simpledrm/simplefb now with the patch gone?

Yup, just 3 posts upthread from your question in #10

ddd wrote:

It does not work only in CachyOS kernel 6.19

Disable building the simple framebuffer device entirely (CONFIG_SYSFB_SIMPLEFB) and the drivers for such (CONFIG_DRM_SIMPLEDRM) become irrelevant.

~ ❯ zgrep SIMPLE /proc/config.gz
# CONFIG_SYSFB_SIMPLEFB is not set

xerxes_ · 2026-03-28 21:13:27

So which kernel parameter is better: initcall_blacklist=simpledrm_platform_driver_init OR initcall_blacklist=sysfb_init?

And I assume that old kernel parameter nvidia_drm.modeset=1 is not working with never kernels?

Last edited by xerxes_ (2026-03-28 21:14:47)

seth · 2026-03-28 21:22:21

> nvidia_drm.modeset=1 is not working with never kernels?
No.

> So which kernel parameter is better:
"initcall_blacklist=sysfb_init" will have broader but earlier impact - it might be "required" and then certainly is better - no idea whether it'd work on hybrid systems

ddd · 2026-03-28 22:26:48

xerxes_ wrote:

So which kernel parameter is better: initcall_blacklist=simpledrm_platform_driver_init OR initcall_blacklist=sysfb_init?
And I assume that old kernel parameter nvidia_drm.modeset=1 is not working with never kernels?

Blacklisting simpledrm_platform_driver_init does not achieve anything for me, according to initcall_debug it does absolutely nothing - neither on my physical host with Nvidia GPU or in a KVM guest. In both cases, simpledrm is already initialized in sysfb_init which is run before that.

Last edited by ddd (2026-03-28 22:38:34)

ddd · 2026-03-28 22:35:26

tekstryder wrote:

ddd wrote:
Did anyone manage to get rid of simpledrm/simplefb now with the patch gone?
Yup, just 3 posts upthread from your question in #10
ddd wrote:
It does not work only in CachyOS kernel 6.19
Disable building the simple framebuffer device entirely (CONFIG_SYSFB_SIMPLEFB) and the drivers for such (CONFIG_DRM_SIMPLEDRM) become irrelevant.
~ ❯ zgrep SIMPLE /proc/config.gz
# CONFIG_SYSFB_SIMPLEFB is not set

I wanted to know whether it is possible to achieve this without (re)building the kernel after the patch/hack removal. Setting simpledrm to N in kernel config is trivial of course, but I want to avoid that if possible.

And it IS possible, blacklisting sysfb_init DOES work. On my host with Nvidia GPU (but without initramfs containing nvidia-open nodules) this results in no framebuffer until drivers are loaded (which is actually good for GPU passthrough scenarios IIRC). In a (K)VM with sysfb_init blacklisted, driver for vfio gpu drm/fb is loaded instead of simpledrm, which is good.

It only does not work for CachyOS kernel 6.19 (the one from their repo, not built from AUR). I thought it also did not work in Arch's official kernel, but I was wrong.

Last edited by ddd (2026-03-28 22:40:09)

xerxes_ · 2026-03-29 10:12:30

@ddd
So you have to compare kernel configs to find the difference and the reason for different behavior of CachyOS kernel and Arch's official kernel.
Current booted kernel config is in /proc/config.gz.

Arch Linux

#1 2025-06-19 10:27:52

Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#2 2025-06-19 10:42:21

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#3 2025-06-19 11:01:28

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#4 2025-06-19 11:18:21

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#5 2025-06-19 11:19:42

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#6 2025-06-19 11:23:00

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#7 2025-06-19 11:24:59

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#8 2025-06-19 11:30:17

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#9 2025-06-19 11:55:56

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#10 2025-06-19 13:43:39

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#11 2025-06-19 17:17:29

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#12 2025-06-19 19:49:23

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#13 2026-03-27 20:58:57

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#14 2026-03-27 21:10:05

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#15 2026-03-27 21:14:24

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#16 2026-03-27 21:50:20

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#17 2026-03-27 23:42:42

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#18 2026-03-28 07:16:13

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#19 2026-03-28 17:09:07

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#20 2026-03-28 21:13:27

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#21 2026-03-28 21:22:21

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#22 2026-03-28 22:26:48

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#23 2026-03-28 22:35:26

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

#24 2026-03-29 10:12:30

Re: Kernel-Parameter: CONFIG_DRM_SIMPLEDRM from "y" to "m"?

Board footer