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