[Xf86-video-armsoc] ARMSOC X11 plugin issues

[Maxime Ripard]

Hi,

So I've finally solved these issues.

On Wed, Mar 23, 2016 at 10:17:05PM +0100, Maxime Ripard wrote:
> Hi David, Marico,
> 
> I've been developping a DRM/KMS driver for the Allwinner SoCs[1], with
> an additional patch to allocate GPU buffers [2]. Since those SoCs also use
> a Mali GPU, using the armsoc X11 plugin seemed like a logical choice.
> 
> I added support for the driver based on the 1.4 plugin [3], and
> started using it, which turned out pretty well, we get something
> displayed, GLES works, good.
> 
> However, after testing it for a while, the first thing we noticed was
> that some (large) buffer allocations would start to fail. Indeed, the
> plugin seems to do a lot of rather small (and for most temporary ?)
> buffer allocations, which eventually depletes the reserved memory
> pool. The allocation then fails, and the application crashes.

Applying this patch [1] from Daniel's repo works around that, and we
don't notice it anymore.

Any reason it's never been merged?

> Then, we noticed (using xfce4, on debian jessie) that the systray
> icons were not displayed for some reason.

This patch [2] from Rockchip's repo fixes that issue, somehow.

> There's also some game (alex4 [4]), that starts, runs, but the
> window content remains black (but it remains interactive, audio
> plays and if we take a screenshot, the content is on the image, but
> the screen remains black).

And this is one is interesting.

The difference was that, on that game window (and some other part of
the screen too), the alpha component was set to !0xff with
armsoc. Forcing an XRGB format (and effectively dropping the alpha
component) when ARGB was requested made everything work.

modesetting, on the the other end, doesn't seem to use alpha at all,
which explains the difference of behaviour.

On my hardware, there's not really a primary plane, there's just 4
identical planes, and one of them had to be used as primary
plane. This is nice since you can use any plane for any purpose, but
it doesn't seem to like having an alpha on the lowest plane (which is
the primary plane in our case).

Setting a background color in the display engine actually displays
that color where alpha is set, so it really seems like the display
engine tries to use alpha, and since there's only black below it,
displays black, instead of ignoring it entirely.

Setting the plane global alpha to 0xff also solves the issue.

However, I don't think it's such a good idea to use alpha on the
primary plane at all, what's your take on this?

Thanks!
Maxime

1: https://github.com/mripard/xf86-video-armsoc/commit/0bf713bdbbd514ea838704282a648f4d044c01e0
2: https://github.com/mripard/xf86-video-armsoc/commit/d8fc72b8f5b70eafd1d84e535d0be08087b7ad3a

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.x.org/archives/xf86-video-armsoc/attachments/20160628/c6fe63bc/attachment.sig>