Depth 30 enablement for ati-ddx + exa. Rev 3

Mario Kleiner mario.kleiner.de at gmail.com
Mon Jan 22 02:14:33 UTC 2018


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



More information about the amd-gfx mailing list