Re: non-PCI driver name lookup

[maya%netbsd.org@localhost]

On Tue, Jul 09, 2019 at 03:32:12PM +0100, Robert Swindells wrote:
> 
> I wrote:
> >On 2019-07-09 14:23, maya%netbsd.org@localhost wrote:
> >> On Tue, Jul 09, 2019 at 11:07:37AM +0100, Robert Swindells wrote:
> >>> 
> >>> maya%netbsd.org@localhost wrote:
> >>> >On Sun, Jul 07, 2019 at 11:23:14PM +0100, Robert Swindells wrote:
> >>> >>
> >>> >> The pinebook uses the modesetting X11 driver.
> >>> >>
> >>> >> An application that calls DRI2Connect() doesn't get back valid values
> >>> >> for device name and driver name so typically assumes that DRI2 isn't
> >>> >> available.
> >>> >>
> >>> >> This looks to be down to how libdrm tries to work out which driver is
> >>> >> being used from an open file descriptor. I presume the NetBSD specific
> >>> >> code in it does work for PCI devices but it looks like we need to add
> >>> >> something for display devices that are built into the CPU.
> >>> >
> >>> >I assume, although I can't find proof that it's the case, that you want
> >>> >to adjust the 'unique' value.
> >>> >
> >>> >arm/nvidia/tegra_nouveau.c
> >>> >257:	master->unique = kmem_asprintf("platform:tegra_nouveau:%02d", id);
> >>> 
> >>> The 'unique' value ought to be fine, there is code in
> >>> arm/sunxi/sunxi_drm.c to create it, but it never gets called.
> >>> 
> >>> >I think the code in libdrm looks at this value via DRM_IOCTL_GET_UNIQUE,
> >>> >but I'm not sure.
> >>> 
> >>> It does, and creation of the unique value should be done lazily from
> >>> the DRM_IOCTL_SET_VERSION ioctl. This ioctl fails as the is_master
> >>> member of the file struct for the drm device isn't set. Not got any
> >>> further in tracking down why.
> >>> 
> >>> 
> >> 
> >> You might find the description here useful,
> >> https://github.com/coypoop/drm/blob/maya-drm51/sys/external/bsd/drm2/dist/drm/drm_ioctl.c#L79-L99
> >
> >That doesn't match what libdrm is actually doing.
> 
> It might be better to say that libdrm when called from typical
> applications isn't doing what is described in that comment.
> 
> I don't think that applications or higher level libraries should need to
> work out whether they are connecting to a PCI graphics device or
> something else and to call different libdrm functions to work with it.
> 
> I'm testing this with multimedia/libva-utils and multimedia/libva,
> running 'vainfo' should be able to get back 'sunxi' as the name of
> the DRI2 device in use on the pinebook, then fail because there isn't
> yet a libva driver for it.

You can force libva to use a particular driver with,
LIBVA_DRIVER_NAME=drivername

Which would at least stop you getting stuck...