Merge pull request #40 from Vesuri/master

[qtwayland] Don't assert on a missing output
[nox11] backport of https://qt.gitorious.org/qt/qtwayland/commit/10700eb19191879caf41bc188dca807b68a4146c
Merge pull request #42 from mer-packages/fix-xkb

[nox11] backport of https://qt.gitorious.org/qt/qtwayland/commit/10700eb...
Revert "Don't disown() buffer until a new texture id is requested"

This reverts commit af3b94e76278f0c94ca146c7aab816073145cd6f.
Revert "Immediately send frame callback on detach"

This reverts commit 6cf69e8ed0600a510c6fed2ec886e58b4f49e022.
Revert "Add QT_WAYLAND_COMPOSITOR_NO_THROTTLE"

This reverts commit 8421e5b8b160d7f31adeafab7225cc5e4b7467c7.
Fix buffer handling.

The surface now has a distinct back and front buffer. Front means it
is on the screen and being used as a texture. Back means it should be
put to screen in the next updatePaintNode().

For the purpose of QML and GUI-thread properties, the 'back' buffer is
what contains the correct properties as it is what it will eventually
be rendered with. For the purpose of rendering, the front buffer
contains the right texture. If no back buffer is present, then there
was no changes and front buffer applies to both.

The Surface's buffer queue has been updated to only fire damage and
advance once we swap back buffer to front buffer which happens during
updatePaintNode(). The fact that the buffer advancing happens during
sync also means that we are releasing buffers back to the client as
soon as another buffer is ready to be displayed in the compositor.
This is "half a frame" earlier than the current implementation (which
releases after the next swap). We consider this safe because:

 - The compositor has a new buffer to display and does not need the
   old one.

 - If the GPU is not done rasterizing the scanout buffer for the
   previous frame, it should hold a read-lock on the buffer so
   preventing the client from starting a render to it. If this
   assumption fails on any hardware we can make the time of
   buffer-advance optional. Either during "sync" or during "after
   rendering" as it is today, but "after rendering" will not offer any
   guarantee, just more time, resulting in a higher chance of the
   buffers being ready. Aka, without an internal read-lock and no
   fence mechanism, there is no guarantee.

Texture cleanup is now explicit as we have a well defined location to
clean up textures, during updatePaintNode(). This avoids cleanup
issues which previously existed as buffer cleanup was happening on the
GUI thread. Surface and Buffer destruction coming over wayland is
queued up in compositor and handled before the next "sync", when it is
safe to do so.

The change also removes doUpdate, postBuffer and frameSwappedInternal
as these are no longer used. Direct rendering will need to be
considered in a new light with the new buffering scheme, and anyway
needs work.

Change-Id: I2db0385b4b8859f96caba374f3530448178e1473
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>

Conflicts:
	qtwayland/examples/qwindow-compositor/qwindowcompositor.cpp
	qtwayland/examples/qwindow-compositor/qwindowcompositor.h
	qtwayland/src/compositor/compositor_api/qwaylandcompositor.h
	qtwayland/src/compositor/wayland_wrapper/qwlsurface.cpp
	qtwayland/src/compositor/wayland_wrapper/qwlsurfacebuffer.cpp
Allow resizing the Qt window after the buffers swap

Some EGL implementations resize the EGL buffers after eglSwapBuffers,
so we need to send the geometry change event after the swap, or else
the Qt window size and the physical buffer size will be different to
each other. Do not force this behavior though, but use it only when
the QT_WAYLAND_RESIZE_AFTER_SWAP environment variable is set.

Change-Id: I79e39442b3010c563a81d7c94e747a982e158fc1
Reviewed-by: Gunnar Sletta <gunnar.sletta@jollamobile.com>
Merge pull request #44 from giucam/resize_fix

Allow resizing the Qt window after the buffers swap
Don't queue up client buffers while the screen is off

This results in the clients being blocked, potentially preventing
them from sending "wakeup" signals which in turn should wake
the compositor. This blocked alarm.
Merge pull request #45 from sletta/blocked-clients

[bugfix] Don't queue up client buffers while the screen is off
[bugfix] Avoid potential crash when closing applications in lipstick
Merge pull request #46 from sletta/delete-guard

[bugfix] Avoid potential crash when closing applications in lipstick
[compositor] Release buffers back to client when window is hidden
Merge pull request #47 from sletta/release-on-hide

[compositor] Release buffers back to client when window is hidden
[compositor] Retain one buffer, also when compositor is hidden
Merge pull request #48 from sletta/hide-take-two

[compositor] Retain one buffer, also when compositor is hidden
[compositor] Release SHM buffers after we've bound the texture.

We have a copy after that so we don't need it. Clients which
are blocked on buffer release get a good benefit from this earlier
release. For this to work, we need to make sure that we don't
access the buffers after it has been disowned, so we store
all the state we need when we set the back buffer.
Merge pull request #49 from sletta/master

[compositor] Release SHM buffers after we've bound the texture.
[compositor] Prevent crash when extended surface is destroyed.

The surface is not destroyed synchronously with the extended surface
so there is a small chance that something accesses
Surface::extendedSurface() between the time when the extended
surface is destroyed and the Surface itself is cleaned up.

We also want to make sure that the extended surface is not hanging
around after the surface is destroyed, so nuke it immediately on
surface_destroy_resource.