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
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
