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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2018-01-22 03:14 AM, Mario Kleiner wrote:
> 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.

Thanks for the thorough testing.

The patches look mostly good now, apart from some cosmetic issues (lines
shouldn't be unnecessarily shorter than 72 columns, and acronyms should
be spelled in all upper case, in the commit logs), but I can live with
those.

However, I gave the patches a quick spin (without a 30-bit capable
monitor though) on the Turks card that's currently sitting in my
development machine, and I noticed that Xorg crashes on shutdown because
the XvMC extension failed to initialize. Can you take a look?


> 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.

I stumbled over this myself the other day. There's an issue with the
(un)wrapping of miPointerSpriteFuncRec entries. Not sure yet what
exactly's wrong with it though. I'll look into it.


> 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.

Hmm. Can you track down where the "format" value in
radeon_dri2_create_buffer2 comes from? It's supposed to be the depth.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux