Set MONITOR_EDID_COMPLETE_RAWDATA flag

Setting this flag results in the entire EDID (including CEA extension)
becoming available to clients via X properties, rather than just
the first 128 bytes.
Add CRTC properties to the list of Xrandr properties
Fix mouse position when underscan is enabled
Use underscan properties to crop display
Dist stuff

Pass foreign flag to automake, as we don't have AUTHORS
Add script to make patch
Create UMP handle for each GEM allocation

Use a new ioctl in exynos-drm to allocate memory and also get a UMP
ID along with it. In the Mali world, UMP IDs are passed in the DRI2
buffer name in order to share GL buffers between client and server.

Kernel patch is https://gist.github.com/dsd/8fe8b84fe53e2b0688f5

Thanks to Daniel Stone and Sjoerd Simons for basically spelling
out this patch in an IRC discussion.
Lookup BO name directly

Now that we allocate names at bo creation time, we can simplify this API.
Only allocate DRI2 pixmaps with GEM

The driver is currently set up (via EXA) to handle all pixmap allocations
itself, and it passes them to GEM.

However, running non-3D apps tends to generate a large number of small
pixmap allocations that we're never going to pass to GL, and it is
expensive and pointless to send them through GEM in this case.

To solve this, fbturbo and my earlier armsoc work for r3p2 strips out EXA,
falling back to X's fast default implementation of pixmap allocation in
the fb layer, then we would migrate such pixmaps to GEM the first time
DRI2 interaction is requested.

However, especially with growing interest in using the CPU cache for a
future performance increase, EXA's PrepareAccess and FinishAccess hooks
are looking more and more useful. In order to use them, we also have to
take over allocation of all pixmaps, but we can do it better: we can
use usage_hint to determine which pixmaps are backing buffers for windows
(hence likely candidates for DRI2 interaction) and which aren't.

The only remaining complication is to detect which pixmap is going to be
used for scanout, this is a bit hacky but it seems to always be the first
pixmap created after ScreenInit.

Performance differences (at 1080p):

                |  BEFORE   BEFORE  |  AFTER   AFTER
                |  RAW X    MUTTER  |  RAW X   MUTTER
----------------+-------------------+----------------
glxgears (fps)  |  148     140      |  148     137
es2gears (fps)  |  313     290      |  313     295
glmark-es2      |  91      68       |  91      73
gtkperf (time)  |  10.7    13.6     |  7.3     9.7
Remove dmabuf synchronization code

This has no effect on the current setup. The kernel does not have
the dmabuf fences/poll support, and GEM does not have the fsync op
implemented required for msync() to have an effect.
Synchronize texture access with umplock

Via DRI2 CreateBuffers we give the underlying pixmap memory addresses
to Mali. Both Mali and X then access the pixmaps, so we have a
synchronization problem to solve.

Fortunately, libMali can be built with "umplock" functionality,
which basically (hopefully) means that Mali informs the kernel when
it is using a specific texture. We can then use umplock here too,
in order to guarantee synchronized access.
Create cacheable offscreen pixmaps, sync caches with UMP

This enables the CPU cache for offscreen pximaps, a performance increase.

But we must then flush caches in the right places.
We do not worry about the Mali GPU L2 cache here, this does not seem
necessary, maybe Mali itself handles that.

What we do have to worry about is handling the CPU cache for offscreen
pixmaps. Before accessing pixmaps from the CPU, we should invalidate the
CPU cache. And when later returning pixmaps back to the GPU, we should
flush the CPU cache.

Scanout buffers are left as writecombining. I'm not sure where the
appropriate write-combining-buffer flush happens, if at all, but this
seems to be working as-is.

Comparing performance at 1080p to commit 85fe287246d9ba7e8ee:

                  |  BEFORE   BEFORE  |  AFTER   AFTER
                  |  RAW X    MUTTER  |  RAW X   MUTTER
  ----------------+-------------------+----------------
  glxgears (fps)  |  148      137     |  148     139
  es2gears (fps)  |  313      295     |  437     438
  glmark-es2      |  91       73      |  186     140
  gtkperf (time)  |  7.3      9.7     |  6.9     17.4
Wait for pending flips before attempting screen resize

Otherwise things get confused and we crash. I wonder if there is a better
way to handle this.
Scanout buffer reference counting fixes

When changing resolution we would hit assertion failures, attemping to
work with freed buffers.

Improve the reference counting so that a reference is added on the
scanout buffer at server startup, transferred to the new scanout
buffer when it gets changed, and freed on shutdown.

When ModifyPixmapHeader also binds the scanout texture to a pixmap,
we have to create a reference there too, because we unref it in
DestroyPixmap.

Fixes crashes and leaks when changing resolution. For testing, I
ran the following scenarios, ensuring that there were no crashes
or memory leaks:

1. Start raw X session then start and stop es2gears many times.
2. Start raw X session, start and stop mutter many times.
3. Start raw X session, start mutter, change the resolution many times.
4. Start raw X session, start gnome-shell, change the resolution many times.
Work around Mali use-after-free upon window resizing

Two quick successive resizes of the LibreOffice Writer window under
gnome-shell results in momentary visible corruption.

Inspecting the stream of events, it seems that two successive resizes
with `xdotool windowsize --sync` causes 5 flips to happen. Flip number 2
has bad data. In between flips 1 and 2, Mali asks us to destroy the DRI
buffer backing the window size at first resize, then it calls
CreateBuffer on the window drawable at its second resize, then
ScheduleSwap. Suspicious that it frees the previous window buffer so soon.

We discovered that delaying the freeing of the buffer that we were asked
to destroy makes the corruption go away. Looks like Mali has a
use-after-free bug.

We try to work around this in a simple way: we now delay all bo frees
until the next ScheduleSwap. We've done a few tests to confirm as best we
can that ScheduleSwap is indeed a reliable indication from Mali that it
has finished drawing the scene. This workaround works for the mutter case,
but is likely to fail on multi-display setups, complicated compositors
that render more than one flip in advance, etc.

Thanks to Vincent Sanders and Daniel Stone for help understanding this
issue.