[PATCH] drm: add drm device name

[Michel Dänzer]

On 2019-09-17 1:20 p.m., Christian König wrote:
> Am 17.09.19 um 11:27 schrieb Michel Dänzer:
>> 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 at gmail.com> wrote:
>>>>>> Am 17.09.19 um 07:47 schrieb Jani Nikula:
>>>>>>> On Mon, 16 Sep 2019, Marek Olšák <maraeo at gmail.com> 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?
> 
> Well how is userspace currently handling that? The kernel should NOT say
> which driver to use in userspace, but rather which one is used in the
> kernel.

Would that really help though? E.g. the radeon kernel driver supports
radeon/r200/r300/r600/radeonsi DRI drivers, the i915 one i915/i965/iris
(and the amdgpu one radeonsi/amdgpu).

The HW generation identifier proposed in these patches might be useful,
but I suspect there'll always be cases where userspace needs to know
more precisely.


> Mapping that information to an userspace driver still needs to be done
> somewhere else, but the difference is that you don't need to add all
> PCI-IDs twice.

It should only really be necessary in Mesa.


On 2019-09-17 1:32 p.m., Daniel Vetter wrote:
> How are other compositors solving this? I don't expect they have a
> pciid table like modesetting copied to all of them ...

They don't need any of this. The Xorg modesetting driver only did for
determining the client driver name to advertise via the DRI2 extension.


-- 
Earthling Michel Dänzer               |               https://redhat.com
Libre software enthusiast             |             Mesa and X developer