I got my Wayland compositor running with the AMDGPU driver on my
Kaveri APU, but I ran into some weird rendering bugs (future
discussion), so I decided to jump back to using the radeon driver to
try to isolate out AMDGPU driver stack vs wayland+wlroots+compositor.
(My compositor and wlroots work great as a daily driver under linux.
It was entirely possible I had done something that shouldn't work but
does anyway.)

It was relatively more stable/usable under the radeon driver, but I
ran into a problem when trying to run my first wayland application on
NetBSD. Part of my compositor suite is a terminal emulator written
against EGL/OpenGLES2 to avoid any toolkit dependencies (which turned
out to be a great decision for this project!). When it started up,
eglInitialize() loads the gallium radeon driver, which calls into
libdrm to get the PCI ID of the graphics card using the
DRM_RADEON_INFO ioctl with RADEON_INFO_DEVICE_ID in the request field
of the struct passed to the kernel. This was failing with EACCES in
drm_ioctl_permit() on this block:
    /* AUTH is only for authenticated or render client */
    if (unlikely((flags & DRM_AUTH) && !drm_is_render_client(file_priv) &&
            !file_priv->authenticated))
        return -EACCES;

It looks like file_priv->authenticated only gets set in two places:
drm_new_set_master() and drm_authmagic(). The former is for the drm
master (which is the wayland compositor in this case), and the latter
is an ioctl that has the DRM_MASTER permission flag set, which I think
means DRM_AUTH is effectively the same as DRM_MASTER. (There's also
some comments in the definition of DRM_RENDER_ALLOW that implies that
DRM_AUTH is the old style permission.)

I'm not sure if there is some other place file_priv->authenticated
should get set, or if the answer is "this is a bug in libdrm/Mesa", as
they only ever seem to open /dev/dri/cardN and make all ioctl calls
against that device. I wrote a test program that uses libdrm to call
the problem ioctl, and it works great when I open /dev/dri/renderD0.

In the meantime, I commented out that block in my kernel, recompiles
and I was able to open my terminal emulator just fine. After I ironed
out some keymap bugs to get libxkbcommon to understand wscons key
presses, I was able to post a toot from the terminal. Clearly, this is
not a long term solution.

(Sooner or later, I'll have more stuff for AMDGPU and some questions
about rendering bugs.)

Jeff

Reply via email to