[PATCH v2] apps: cam: Skip devices without connectors

[Laurent Pinchart]

On Fri, May 16, 2025 at 05:15:48PM +0200, Milan Zamazal wrote:
> Laurent Pinchart writes:
> > On Thu, May 15, 2025 at 06:25:36PM +0200, Milan Zamazal wrote:
> >> Device::openCard() in the cam DRM helpers looks for a /dev/dri/card*
> >> device that can be opened and that doesn't fail when asked about
> >> DRM_CAP_DUMB_BUFFER capability (regardless whether the capability is
> >> supported by the device).
> >> 
> >> There can be matching devices that are not display devices.  This can
> >
> > Can you share an example of such a device ? Are we talking about a
> > device that sets DRIVER_MODESET but is not a display device ?
> 
> I guess so.  I have the following on TI AM69:
> 
>   # ls -l /dev/dri/
>   total 0
>   drwxr-xr-x 2 root root        100 Mar  7 01:00 by-path/
>   crw-rw---- 1 root video  226,   0 Mar  7 01:00 card0
>   crw-rw---- 1 root video  226,   1 Mar  7 01:00 card1
>   crw-rw-rw- 1 root render 226, 128 Mar  7 01:00 renderD128
> 
>   # ls -l /sys/class/drm/
>   total 0
>   lrwxrwxrwx 1 root root    0 Mar  7 01:00 card0 -> '../../devices/platform/bus at 100000/4a00000.dss/drm/card0'/
>   lrwxrwxrwx 1 root root    0 Mar  7 01:00 card0-DP-1 -> '../../devices/platform/bus at 100000/4a00000.dss/drm/card0/card0-DP-1'/
>   lrwxrwxrwx 1 root root    0 Mar  7 01:00 card0-HDMI-A-1 -> '../../devices/platform/bus at 100000/4a00000.dss/drm/card0/card0-HDMI-A-1'/
>   lrwxrwxrwx 1 root root    0 May 16 14:31 card1 -> '../../devices/platform/bus at 100000/4e20000000.gpu/drm/card1'/
>   lrwxrwxrwx 1 root root    0 May 16 14:31 renderD128 -> '../../devices/platform/bus at 100000/4e20000000.gpu/drm/renderD128'/
>   -r--r--r-- 1 root root 4096 May 16 16:49 version
> 
> card1 causes the problem.

Right. The usual story of out-of-tree drivers being full of bugs. One
day I'll tackle the fundamental unfairness of upstream developers having
to suffer from bugs of non-upstream code. After tackling the other
unfairness that we software developers always have to suffer from
hardware bugs, and never the other way around.

Skipping devices without connectors seems to be the best workaround.
Should we drop the DRM_CAP_DUMB_BUFFER capability query too ?

> >> lead to selection of such a device and inability to use KMS output with
> >> `cam' application.  The ultimate goal is to display something on the
> >> device and later the KMS sink will fail if there is no connector
> >> attached to the device (although it can actually fail earlier, when
> >> trying to set DRM_CLIENT_CAP_ATOMIC capability if this is not
> >> supported).  Let's avoid selecting devices without connectors.
> >> 
> >> A question is whether the added check makes the check for
> >> DRM_CAP_DUMB_BUFFER API redundant or not.
> >> 
> >> Changes in v2:
> >> - Rebased on current master.
> >> 
> >> Signed-off-by: Milan Zamazal <mzamazal at redhat.com>
> >> ---
> >>  src/apps/cam/drm.cpp | 12 ++++++++++++
> >>  1 file changed, 12 insertions(+)
> >> 
> >> diff --git a/src/apps/cam/drm.cpp b/src/apps/cam/drm.cpp
> >> index 47bbb6b0..e19e848c 100644
> >> --- a/src/apps/cam/drm.cpp
> >> +++ b/src/apps/cam/drm.cpp
> >> @@ -479,6 +479,18 @@ int Device::openCard()
> >>  			continue;
> >>  		}
> >>  
> >> +		/* Skip devices without connectors. */
> >> +		std::unique_ptr<drmModeRes, decltype(&drmModeFreeResources)> resources{
> >> +			drmModeGetResources(fd_),
> >> +			&drmModeFreeResources
> >> +		};
> >> +		if (!resources || resources->count_connectors <= 0) {
> >> +			resources.reset();
> >> +			drmClose(fd_);
> >> +			fd_ = -1;
> >> +			continue;
> >> +		}
> >> +
> >>  		found = true;
> >>  		break;
> >>  	}

-- 
Regards,

Laurent Pinchart