GitLab

Now even without using the hardware overlay, ordinary ump buffers
allocated in normal memory don't trigger excessive dri2 buffer
requests from the mali blob.

TODO:
* check for any possible memory leaks, ensure correct refcounting
* test windows resize behavior for both r3p0 and r3p2 blobs
* check if the EVEN/ODD frame order enforcing is still necessary for
  r3p2 (it could be just one more r3p0 quirk that is already gone)

The mali r3p2 blob does not seem to be affected by the window
resize bug anymore, so there is no need to apply the r3p0
workaround (and it does not even work correctly).

When using the hardware overlay, now we need to allocate secure id 1
and 2 for back/front ump buffers. Otherwise the blob is trying to
request a new dri2 buffer for each frame, and this kills performance
(thanks to redundant ump buffers mapping/unmapping). This is now
fixed.

But when not using the hardware overlay, the r3p2 blob is still
requesting dri2 buffer per each frame, and this needs an additional
tweak.

In double buffer mode, explicitly mark the buffers as designated
for odd or even frame position when putting them into queue. And
when swapping the buffers, use these flags to re-synchronize if
it is necessary. This prevents problems after window resize (when
gles-rgb-cycle-demo could expose a mismatch between the color
name in the window title and the actual window color).
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

If DEBUG_WITH_RGB_PATTERN is defined, then we check that the
frames colors are changed as "R -> G -> B -> R -> G -> ..."
pattern and print debugging messages when this is not the
case. Such color change pattern can be generated by the
"test/gles-rgb-cycle-demo.c" program.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

When enabled, it tries to avoid tearing in OpenGL ES applications.
Works on sunxi hardware in the case if the hardware overlay (sunxi
disp layer) is used for a DRI2 window. The name of this option and
the description in the man page has been borrowed from intel and
radeon drivers.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

That's the right thing to do and fixes issues such as
    https://github.com/ssvb/xf86-video-sunxifb/issues/6



As a result, now the framebuffer size may need to be larger in
order to accomodate two DRI2 buffers in the offscreen part of
the framebuffer. The users of sunxi hardware are advised to
increase the value of fb0_framebuffer_num variable in fex file
to 3 for 32bpp mode and to 5 for 16bpp mode.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

When moving further to our own DRI2 buffers bookkeeping, we can't
really trust the information from DRI2BufferRec anymore. So just add
a copy of all the missing bits of information to UMPBufferInfoRec
and use it instead.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

The recent commit 9e0a8731

 (its part
that suppressed buffers reuse in the Xorg DRI2 framework) introduced
a regression. Half of the frames stoppped reaching the screen on
the CPU copy fallback path because the Mali blob now ended up
rendering them to the "wrong" buffer.

It just confirms that we need to completely move from the standard
DRI2 framework in the Xorg server to our own buffers bookkeeping
logic. This patch fixes the regression by introducing a single UMP
buffer per window, which is shared between back and front DRI2
buffers. We can do this because double buffering does not make much
sense on the fallback path at the moment (we can't set scanout from
this buffer and anyway have to copy this data elsewhere immediately
after we get it from Mali).
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Using the secure id 1 (framebuffer) to trick the Mali blob into
requesting DRI2 buffers again was not a very good idea. The problem
is that the blob still writes something there and corrupts the
framebuffer. So instead we try to assign secure id 2 to a dummy
4KiB UMP buffer allocated in memory and use it for the same purpose.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

The Mali blob is doing something like this:

 1. Request BackLeft DRI2 buffer (buffer A) and render to it
 2. Swap buffers
 3. Request BackLeft DRI2 buffer (buffer B)
 4. Check window size, and if it has changed - go back to step 1.
 5. Render to the current back buffer (either buffer A or B)
 6. Swap buffers
 7. Go back to step 4

A very serious show stopper problem is that the Mali blob ignores
DRI2-InvalidateBuffers events and just uses GetGeometry polling
to check whether the window size has changed. Unfortunately this
is racy and we may end up with a size mismatch between buffer A
and buffer B. This is particularly easy to trigger when the window
size changes exactly between steps 1 and 3.

See test/gles-yellow-blue-flip.c program which demonstrates this.
Qt5 applications also trigger this bug.

We workaround the issue by explicitly tracking the requests for
BackLeft buffers and checking whether the sizes of these buffers
match at step 1 and step 3. However the real challenge here is
notifying the client application that these buffers are no good,
so that it can request them again. As DRI2-InvalidateBuffers
events are ignored, we are in a pretty difficult situation.
Fortunately I remembered a weird behaviour observed earlier:

    https://groups.google.com/forum/#!msg/linux-sunxi/qnxpVaqp1Ys/aVTq09DVih0J



Actually if we return UMP secure ID value 1 for the second DRI2
buffer request, the blob responds to this by spitting out the
following error message:

    [EGL-X11] [2274] DETECTED ONLY ONE FRAMEBUFFER - FORCING A RESIZE
    [EGL-X11] [2274] DRI2 UMP ID 0x3 retrieved
    [EGL-X11] [2274] DRI2 WINDOW UMP SECURE ID CHANGED (0x3 -> 0x3)

And then it proceeds by re-trying to request a pair of DRI2 buffers.
But that's exactly the behaviour we want! As a down side, some ugly
flashing can be seen on screen at the time when this workaround kicks
in, but then everything normalizes. And unfortunately, the race
condition is still not totally eliminated because the blob is
apparently getting DRI2 buffer sizes from the separate GetGeometry
requests instead of using the information provided by DRI2GetBuffers.
But now the problem is at least very hard to trigger.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

The modern desktops may use ARGB cursors. As the current
sunxi display controller support code can't handle this
type of cursor yet, the X server fallbacks to a software
cursor which is not visible under layers and ruining user
experience.

This patch adds empty implementations for "UseHWCursorARGB"
and "LoadCursorARGB" functions which just return error for
now (so that the X server still fallbacks to software cursor).
However we also introduce callback functions responsible for
notifying the DRI2 code about enabling/disabling the use of
hardware cursor. So that now hardware overlays are disabled
when switching to software cursor and re-enabled again when
switching back to hardware cursor.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Testing with gnome-shell revealed a problem. We need to migrate
pixmaps into UMP buffers in order to allow the GLESv2 based
compositing manager to actually access the content of redirected
windows, rendered by X11 applications into offscreen pixmaps.

Just to make sure that we don't add any unneeded overhead for 2D
(neither extra CPU cycles nor the increase for unrelated pixmaps
memory footprint), a hash table (currently uthash [1]) is used
for connecting DRI2-enabled pixmaps with UMP buffers. The lookups
are only performed on DRI2 buffer creation and pixmap destruction.

1. http://troydhanson.github.com/uthash/

Reported-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

The driver can use sunxi display controller layers for fully visible
windows, avoiding expensive memory copy.

Hardware cursor is necessary because it is also visible on
top of sunxi disp layers, while software cursor is not.

FIXME: there is one minor problem with negative cursor
positions. The hardware does not support them, so such
positions are just set to 0 for now. In the future this
can be solved better by changing the cursor picture and
showing only the parts which are visible on screen.