Draft: loader,glx: Do not request SCANOUT resources for XWayland

Explicitly requesting a SCANOUT resource can lead to using less efficient buffer formats and on kmsro devices forces the use of an imported buffer from the display controller device. This may make sense for native X clients that might fullscreen and end up scanned out directly, but it makes a lot less sense for XWayland clients with a compositor above them.

Detect XWayland and disable the SCANOUT flag for dri3 buffers in that case. This is only implemented for GLX/DRI3 so far.

--

This is something I stumbled upon while debugging resource modifiers/formats on asahi. This is a partial implementation for glx/dri3 only, which is enough to make glxgears use compressed framebuffers on XWayland (as native Wayland eglgears already does). If this makes sense I'll fill out the egl/dri2 combinations, but first I want to know whether I'm on the right track at all here, since I don't have much context about the rest of the stack here ^^

One question I have is whether XWayland clients can do fullscreen passthrough scanout at all on Wayland compositors. Would that get passed through the layers at all? But if so, I'm not sure that is worth forcing every X11 surface to be a dumb buffer. On our hardware I wouldn't be surprised if rendering to an efficient tiled and compressed framebuffer (especially with multiple render passes) and then compositing/blitting to a linear one once is faster than doing a bunch of render passes on an unoptimized linear buffer that you can then present directly.

Which also begs the question of whether we want to force that kind of behavior on native Wayland apps that might try to get scanout buffers when fullscreen... Though this might be moot once we implement compressed scanout buffers in the display controller, but we're not there yet.