Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

[Thomas Hellstrom <thellstrom-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>]

On 08/31/2018 05:30 PM, Thomas Hellstrom wrote:
> On 08/31/2018 05:27 PM, Emil Velikov wrote:
>> On 31 August 2018 at 15:38, Michel Dänzer <michel@daenzer.net> wrote:
>>> [ Adding the amd-gfx list ]
>>>
>>> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote:
>>>> On 08/31/2018 02:30 PM, Emil Velikov wrote:
>>>>> On 31 August 2018 at 12:54, Thomas Hellstrom <thellstrom@vmware.com>
>>>>> wrote:
>>>>>> To determine whether a device node is a drm device node or not, 
>>>>>> the code
>>>>>> currently compares the node's major number to the static drm major
>>>>>> device
>>>>>> number.
>>>>>>
>>>>>> This breaks the standalone vmwgfx driver on XWayland dri clients,
>>>>>>
>>>>> Any particular reason why the code doesn't use a fixed node there?
>>>>> It will make the diff vs the in-kernel driver a bit smaller.
>>>> Because then it won't be able to interoperate with other in-tree
>>>> drivers, like virtual drm drivers or passthrough usb drm drivers.
>>>> There is no clean way to share the minor number allocation with 
>>>> in-tree
>>>> drm, so standalone vmwgfx is using dynamic major allocation.
>>> I wonder why I haven't heard of any of these issues with the standalone
>>> version of amdgpu shipped in packaged AMD releases. Does that also 
>>> use a
>>> different major number? If yes, maybe it's just that nobody has tried
>>> Xwayland clients with that driver. If no, how does it avoid the other
>>> issues described above?
>>>
>> AFAICT, the difference is that the standalone vmwgfx uses an internal
>> copy of drm core.
>> It doesn't reuse the in-kernel drm, hence it cannot know which minor 
>> it can use.
>>
>> -Emil
>
> Actually, standalone vmwgfx could perhaps also try to allocate minors 
> from 63 and downwards. That might work, but needs some verification.
>

So unfortuntately this doesn't work since the in-tree drm's file 
operations are registered with the DRM_MAJOR.
So I still think the patch is the way to go. If people are concerned 
that also fbdev file descriptors are allowed, perhaps there are other 
sysfs traits we can look at?

/Thomas




> /Thomas
>

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx