On 2018-08-31 4:46 p.m., Thomas Hellstrom wrote: > On 08/31/2018 04:38 PM, Michel Dänzer 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? >> >> > Is standalone AMD supposed to be able to coexist with in-tree drm drivers? Yes, it does, it's working e.g. on laptops with an Intel integrated and an AMD discrete GPU. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
