Ok, 3rd revision, now with per-x-screen drmmode_crtc_funcs rec and set_gamma = NULL in the depth 30 case. Also back to Fredrik's original exa 10 bit patch, just with his signed-off tacked on. Tested with single and dual x-screen, depth 24, depth 30 and mixed 24 and 30 on separate x-screens. Also tested against current tip of ati-ddx master. In other news: When testing against current master in dual-x-screen mode, i found out that the current ati-ddx commit at the top 1fe8ca75974c52 "Keep track of how many SW cursors are visible on each screen" breaks multi x-screen setups by screwing up cursor handling. If i start such a config on KUbuntu 16.04.3 LTS with X-Server 1.19.3 and sddm login manager, the displays come up with the sddm login prompt on the display of x-screen 0, and a black display on screen 1, as expected. Mouse cursor starts off on screen 0. As long as i move the cursor only on x-screen 0 all is fine. As soon as i try to move the cursor to the display of x-screen 1, the cursor disappears, the whole display freezes and top shows x-org consuming 100% of a cpu core, apparently caught in an infinite loop. Attaching gdb suggests it is calling the new cursor handling code of that commit in some infinite loop. I had a look at the commit and couldn't find anything obviously wrong with it. But then i just learned enough about cursor handling to understand that commits logic in the first place, and obviously the machine disagrees with my judgment. Reverting that commit makes everything work again on dual x-screen. Haven't tested on amdgpu-ddx but if it has the same patch i'd expect the same breakage. I am also currently looking into broken pageflipping with the ati-ddx under DRI2. This seems to be due to recent changes in the drmAddFB() calls to no longer pass in the depth/bpp of the x-screens root window pixmap, but instead the depth/bpp of the pixmap that should be flipped onto the scanout. On DRI3 this behaves as i'd expect, but on DRI2 the passed in pixmaps don't seem to have depth 24 on a depth 24 screen or depth 30 on a depth 30 screen, like the root windows, but instead the pixmaps come in at depth 32. That leads the pagelip ioctl to fail, with the kernel complaining that "Page flip is not allowed to change frame buffer format." If i hack mesa gallium/st's dri2_drawable_get_buffers() to avoid use of the DRI2GetBuffersWithFormat() request and instead use the older DRI2GetBuffers() request, then pageflips work again, as the old request derives the buffers depth from the glx drawables depth, which is 24 or 30 for a depth 24 or depth 30 x-screen, so a better match. thanks, -mario
