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@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?
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.