Video card being being added as card1 instead of card0.

[runta]

Not sure if this is due to an update or something else I did but for some reason my video card is being added as /dev/dri/card1 instead of /dev/dri/card0. /dev/dri/card0 does not exist.
I have some scripts that target /dev/dri/card0 which I can update to look for all cards and find the correct one but before I even do that I want to understand why card0 is being skipped.
Does anyone have any idea why this might be happening or what I can do to fix/diagnose this?
Today did a system update(sorry don't know everything that got updated) and installed v4l2loopback-dkms could either of these be the reason for this issue?
On Arch Linux with linux-zen 6.4.9.zen1-1.

 

[osprey]

Could be a mismatch of kernel and modules. See here if there's any help: https://bbs.archlinux.org/viewtopic.php?id=263321

 

[runta]

Unfortunately doesn't seem to be the issue, the card works its just added as card1 instead of card0 and there is no card0.

Edit:

Installed linux-lts 6.1.44-1-lts and the video card was placed in the card0 slot. This seems to be a kernel bug, happens on Zen and regular Arch Linux kernel.

 

[osprey]

Unfortunately doesn't seem to be the issue, the card works its just added as card1 instead of card0 and there is no card0.

Edit:

Installed linux-lts 6.1.44-1-lts and the video card was placed in the card0 slot. This seems to be a kernel bug, happens on Zen and regular Arch Linux kernel.

It turns out upon investigation that the numbering of the DRM devices is not necessarily consistent with the number of graphics cards in the system. Usually /dev/dri/card0 is used for the graphics card that is integrated on the motherboard whilst /dev/dri/card1 would then be allocated to the graphics adapter plugged in on a PCI bus, but the kernel allocates things as it finds them and it doesn't always do so in the same way due to (near) parallel processing, different states on different boots and other factors. So the finding on your system is not likely at all to be a kernel bug, rather a more obscure kernel functioning.

Hybrid graphics on a system usually allocate /dev/dri/card1 to the discrete adapter rather than the integrated one. Without knowing your system, I can't say whether this likelihood was occurring.

In any case, I'm glad the new kernel resolved the issue.

 

[runta]

It turns out upon investigation that the numbering of the DRM devices is not necessarily consistent with the number of graphics cards in the system. Usually /dev/dri/card0 is used for the graphics card that is integrated on the motherboard whilst /dev/dri/card1 would then be allocated to the graphics adapter plugged in on a PCI bus, but the kernel allocates things as it finds them and it doesn't always do so in the same way due to (near) parallel processing, different states on different boots and other factors. So the finding on your system is not likely at all to be a kernel bug, rather a more obscure kernel functioning.

Hybrid graphics on a system usually allocate /dev/dri/card1 to the discrete adapter rather than the integrated one. Without knowing your system, I can't say whether this likelihood was occurring.

In any case, I'm glad the new kernel resolved the issue.

Sorry if I wrote that in some confusing way, the issue is in the newer kernel not the other way around unfortunately. In LTS the issue doesn't happen. I'll have to put up a bug report when I have some time.
I don't have any other dedicated/integrated GPUs.

 

[runta]

Caused by CONFIG_SYSFB_SIMPLEFB set to y in kernel 6.4.8. SimpleFB now loads before AMDGPU causing the problem, using "initcall_blacklist=simpledrm_platform_driver_init" as a kernel parameter(can cause longer boot times) can mitigate the issue. (https://bbs.archlinux.org/viewtopic.php?id=288578). Adding this info incase someone gets here through a Google search.