[libcamera-devel] [PATCH v3] cam: drm: Support /dev/dri cards other than 0

[Javier Martinez Canillas]

Hello,

On 6/9/22 18:13, Eric Curtin wrote:

[snip]

>>>> Existing code is hardcoded to card0. Since recent fedora upgrades, we
>>>> have noticed on more than one machine that card1 is present as the
>>>> lowest numbered device, could theoretically be higher.
>>>
>>> Out of curiosity, why is that ?
>>
>> I don't know, I didn't mind too much, because this patch fixed it and
>> it seemed like the more correct way anyway. CC'ing Javier, just in
>> case he knows, being a DRM guru. I've seen it on 2 machines I own that
>> updated recently and Ian also saw it on his machine.
> 
> I got an answer on this, it is believed on modern kernels, simpledrm
> will register as card0, then the real hardware-accelerated driver will
> register as card1 which will cause simpledrm driver (or card0) to be
> kicked out. Regardless, this was seen as a userspace bug as it should
> not be assumed that if there is one card registered that it is card0,
> there are no guarantees here.
> 

To elaborate on this, before F36 we used the {vesa,efi,simple}fb drivers to
have early video output but since F36 those have been replaced by simpledrm
that as any DRM driver registers a DRI device (as card0 since is the first
driver probed due being built-in the kernel).

Later, a real DRM driver is probed and registers its own DRI device. These
should remove all conflicting framebuffers when probed, but not all drivers
do this at the same time.

For example, the i915 driver first calls to devm_drm_dev_alloc() function [0]
and then calls to drm_aperture_remove_conflicting_framebuffers() [1]. There's
a small window then where one has two DRI devices between the time when i915
registers its device and the DRM core kicks out the simpledrm driver.

Other DRM drivers call drm_aperture_remove_conflicting_framebuffers() at the
beginning of their probe function so there will only be a single DRI device
at any point.

I asked the DRM folks if they would accept a patch to move the conflicting FB
removal earlier but they said that's a user-space bug as Eric mentioned, since
is a fragile assumption to make anyways.

[0]: https://docs.kernel.org/gpu/drm-internals.html?highlight=devm_drm_dev_alloc#c.devm_drm_dev_alloc
[1]: https://docs.kernel.org/gpu/drm-internals.html?highlight=remove_conflicting_framebuffers#c.drm_aperture_remove_conflicting_framebuffers

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat