Revert "Move wakeup handler to per-fd not per-Screen"

This reverts commit 04af999d33be6d2b748142c66d054c9287b314e1.

This does not work quite right as because the server calls
InitBlockAndWakeupHandlers() for each server generation, which wipes
out any event handlers that were installed with the changes in this
patch.

Fixes the ability to run:
  X &
  mutter &
  killall mutter
  mutter &

etc.
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.
Fix crashes when no display is connected at startup

Under such conditions, we were dereferencing a NULL last_good_mode
pointer, and also dereferencing a NULL encoder.
Allocate framebuffer on unflippable-to-flippable transition

The previous_canflip system that was in place no longer works,
because DRI2 on the X side no longer checks serial numbers.

We need a new way to detect the situation where a framebuffer was
not created at CreateBuffer time (because the window wasn't mapped)
but then later becomes mapped and flippable.

After some experimentation I have settled on the assumption that Mali
always sends a GetBuffers request when such a transition happens,
which means we can hook into ReuseBufferNotify to be called at that time
and create the framebuffer.

This fixes a test case of running `glmark2-es2 --fullscreen` under
metacity with xserver commit 77e51d5bbb97eb5c9d9dbff9a7c44d7e53620e68
applied. Previously it was falling back to CopyRegion (fb never allocated),
now we allocate the fb once the window gets mapped shortly after launch.
Check for encoder before checking for overscan compensation

When X is started without a display, and then you connect a display
later, we'll arrive in this function with no encoder available
(X is seeing what display modes are available before deciding whether
to enable the display or not). The function is then called again later
with an encoder available.

Fix a segfault when there is no encoder.
Add missing initialization

The last commit lacks some variable initialization for the case
where there is no encoder. My mistake when I modified the original
patch. Thanks to Vivek for pointing this out.
Fix performance issue when enlightenment started.

Change some logic in ARMSOCDRI2ScheduleSwap(). If src and dst has
same size and they are both no-framebuffer with compositor enabled,
we only need to exchange buffers between src and dst pixmap.

Change-Id: Iba0b3e248589bc8d05f5b52cfb12865790d812a3