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

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

 



On Fri, Aug 31, 2018 at 11:32 AM Christian König
<ckoenig.leichtzumerken@xxxxxxxxx> wrote:
>
> Am 31.08.2018 um 17:27 schrieb Emil Velikov:
> > On 31 August 2018 at 15:38, Michel Dänzer <michel@xxxxxxxxxxx> 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@xxxxxxxxxx>
> >>>> 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.
>
> The amdgpu pro package has it's own drm core copy as well and there it
> still works.

We don't use our own copy of drm core in the kernel, we rely on the in
kernel one.  Just ttm and amdgpu are updated in the dkms packages.

Alex

>
> Not sure how our back-porting guys handle that.
>
> Christian.
>
> >
> > -Emil
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
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