Re: [PATCH] drm: add drm device name

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 17 Sep 2019 13:32:05 +0200
Daniel Vetter <daniel@xxxxxxxx> wrote:

> On Tue, Sep 17, 2019 at 11:27 AM Michel Dänzer <michel@xxxxxxxxxxx> wrote:
> >
> > On 2019-09-17 11:23 a.m., Michel Dänzer wrote:  
> > > On 2019-09-17 10:23 a.m., Koenig, Christian wrote:  
> > >> Am 17.09.19 um 10:17 schrieb Daniel Vetter:  
> > >>> On Tue, Sep 17, 2019 at 10:12 AM Christian König
> > >>> <ckoenig.leichtzumerken@xxxxxxxxx> wrote:  
> > >>>> Am 17.09.19 um 07:47 schrieb Jani Nikula:  
> > >>>>> On Mon, 16 Sep 2019, Marek Olšák <maraeo@xxxxxxxxx> wrote:  
> > >>>>>> The purpose is to get rid of all PCI ID tables for all drivers in
> > >>>>>> userspace. (or at least stop updating them)
> > >>>>>>
> > >>>>>> Mesa common code and modesetting will use this.  
> > >>>>> I'd think this would warrant a high level description of what you want
> > >>>>> to achieve in the commit message.  
> > >>>> And maybe explicitly call it uapi_name or even uapi_driver_name.  
> > >>> If it's uapi_name, then why do we need a new one for every generation?
> > >>> Userspace drivers tend to span a lot more than just 1 generation. And
> > >>> if you want to have per-generation data from the kernel to userspace,
> > >>> then imo that's much better suited in some amdgpu ioctl, instead of
> > >>> trying to encode that into the driver name.  
> > >>
> > >> Well we already have an IOCTL for that, but I thought the intention here
> > >> was to get rid of the PCI-ID tables in userspace to figure out which
> > >> driver to load.  
> > >
> > > That's just unrealistic in general, I'm afraid. See e.g. the ongoing
> > > transition from i965 to iris for recent Intel hardware. How is the
> > > kernel supposed to know which driver is to be used?
> > >
> > >
> > > For the Xorg modesetting driver, there's a simple solution, see
> > > https://gitlab.freedesktop.org/xorg/xserver/merge_requests/278 .
> > > Something similar can probably be done in Mesa as well.  
> >
> > Another possibility might be for Xorg to use
> > https://www.khronos.org/registry/EGL/extensions/MESA/EGL_MESA_query_driver.txt
> > to determine the driver name. Then only Mesa might need any HW specific
> > code.  
> 
> How are other compositors solving this? I don't expect they have a
> pciid table like modesetting copied to all of them ...

Hi,

other compositors have no driver-specific code at all, so they do not
need to know what the driver in kernel or Mesa is, or what chip they
are running. They may report chip name and stuff in logs for the users'
amusement, but nothing more.

Even the NVIDIA proprietary driver detection happens through EGL
extension search: no-one else exposes EGLStreams.

Unless maybe if someone needs to quirk around driver bugs.


Thanks,
pq

Attachment: pgpVueTNv17Bu.pgp
Description: OpenPGP digital signature

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux