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 <mic...@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 <thellst...@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
