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

[Laurent Pinchart]

Hi Javier and Eric,

On Thu, Jun 09, 2022 at 07:59:58PM +0200, Javier Martinez Canillas wrote:
> 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.

Thank you for the information. This makes sense.

> [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

-- 
Regards,

Laurent Pinchart