[Xf86-video-armsoc] Default visual depth 32

[Daniel Drake]

Hi,

First, a quick run-down of the problem we are facing:

armsoc, rather unconventionally, sets a default visual depth of 32.
This means that the root window pixmap has depth 32, i.e. it has an
alpha channel. That's strange as you would not need any alpha on the
root pixmap, there is nothing behind it which we could blend it with.
Anyway...

The desktop runs under this configuration, and the norm is that X
windows from apps run at the same depth as their parent (the root
pixmap). So now, app windows are running with depth 32, i.e. they have
an alpha channel, even if they are not ever going to be anything other
than opaque.

We're running a composited desktop environment, so the apps are
actually rendered in off-screen memory, and the compositor has the
task of putting them on the screen. The compositor notes that the
windows have depth 32, so they have an alpha channel, so instead of
doing the fast-path blit onto the screen, it has to blend them with
the rest of the desktop contents, because they might have some level
of transparency.

The extra cost of doing this blend is very noticeable when running on
low-power ARM systems, playing video at high resolution.

Having spent a few hours studying this in order to get up to scratch
and be able to understand this issue, I can see that X is really
painful to work with here. Old design, docs not great, the whole thing
is quite confusing. Any bugs in Mali/armsoc here are totally
understandable. But luckily I have colleagues who are very experienced
with X so I hope we can work together, understand this, and get it
fixed properly.

The question is, why does armsoc set the default visual depth to 32?
It has originated from this commit, but I don't get the reasoning:

commit c0bc3fb1f9a1a975c060d6db381498a2e2126a53
Author: David Garbett <David.Garbett at arm.com>
Date:   Wed Sep 26 14:08:29 2012 +0100

    Change default visual to have a depth of bitsPerPixel.

    This results in the default visual including alpha in the depth.
    This is the behavour expected by the xorg render implementation, so appears
    to be reasonably standard.

I'd disagree with it being "reasonably standard" - every other modern
DDX that I've looked at sets the default visual depth to be the same
as the screen's depth.

A more recent commit added a comment here:
 /* We create a single visual with the depth set to the
 * screen's bpp as otherwise XComposite will add an alternate
 * visual and ARGB8888 windows will be implicitly redirected.
 * The initial scanout buffer is created with the same depth
 * to match the visual.
 */

I don't quite grasp this either. Composite is specially designed to
allow the common case of depth 32 windows (transparent through to
whatever's behind them) on top of a depth 24 root window. No need for
special consideration at the DDX level.

Could it be that this is all being done to work around bugs in Mali's
EGL implementation? I already found 2 Mali-400 bugs that are related
to visuals and I've reported them through the appropriate channel.

Thanks for any clarification!
Daniel