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

[Dave Airlie]

On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom <thellstrom at vmware.com> wrote:
>
> On 09/03/2018 06:33 PM, Daniel Vetter wrote:
> > On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote:
> >> 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 at 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 at 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?
> > Somewhat out of curiosity, but why do you have to overwrite all of drm?
> > amdgpu seems to be able to pull their stunt off without ...
> > -Daniel
>
> At the time we launched the standalone vmwgfx, the DRM <-> driver
> interface was moving considerably more rapidly than the DRM <-> kernel
> interface. I think that's still the case. Hence less work for us. Also
> meant we can install the full driver stack with latest features on
> fairly old VMs without backported DRM functionality.
>

I think this should be fine for 99% of drm usage, there may be corner
cases in wierd places, but I can't point to any that really matter
(maybe strace?)

Acked-by: Dave Airlie <airlied at redhat.com>

Dave.