Merge pull request #39 from Psychtoolbox-3/master

Pull to resync with PTB 3.0.11 master for release "Hammertime - SP2 - FlowerPower"
Screen/Linux: Fix X11 display locking more.

There was a hidden locking error when running on the FOSS
(Mesa/Gallium) graphics drivers under X11: Each scheduled
doublebuffer-swap will invalidate the drawables system framebuffer.
First access to the fb by OpenGL will therefore trigger a roundtrip to
the X-Server for revalidation. This uses our shared x-display
connection handle for transport and therefore needs lock protection in
multi-threaded ops like frame-sequential stereo of async flips. The
NVidia binary blob uses a different mechanism for revalidation which
bypasses the X-Server, so this problem didn't show up during
pre-release testing.

We can't lock protect any glXXX call just in case, that would be a
performance disaster. Therefore we perform a dummy pixel write +
glFlush() immediately after scheduling a bufferswap and we do this
under display lock protection. This write after bufferswap will trigger
the X11 roundtrip for fb revalidation under the lock. After that
validation we should be safe from such surprises until the next
bufferswap gets scheduled.

Hopefully the last locking bug from our locking rewrite, this is
painful.

-> Screen mex files for 32/64-Bit Matlab/Octave on Linux rebuilt.
-> Tested in VM, but this is mostly pointless.
-> Tests on both NVidia proprietary and nouveau FOSS pending.
Screen/Linux: Fix deadlock in Screen('Resolutions', screenid);

Did deadlock when called that way, due to display locking bug.
Screen/Linux: Next attempt at proper X11 Locking :-(

Approach from previous commit didn't work, because the
rountrip to the X-Server (aka DRI2GetBuffersWithFormat) is
blocking if the bufferswap is still pending. Therefore this
caused massive performance degradation on FOSS drivers.

Now we are more careful to try to avoid blocking with
display lock held:

a) If OML_sync_control is supported, use
   PsychOSGetSwapCompletionTimestamp() to wait in a non-blocking,
   polling way for bufferswap completion, and only then perform
   the dummy-pixelwrite + glFlush() to the framebuffer. This
   guarantees the actual write won't block with lock held.
   PsychOSGetSwapCompletionTimestamp() can now do the waiting
   for swap completion without actual final timestamping and
   INTEL_swap_events processing if the time variable is set to
   NULL to signal we're not interested in the actual (ust,msc).

   If OML_sync_control isn't available or functional, we still
   do the dummy-write, because we have to - Crashing is worse
   than degraded performance!

b) Make sure this fixup/workaround is only executed if multi-threading
   is active, ie., if a async flip is pending or our homegrown frame-
   sequential stero mode is active. Skip this stuff in purely single-
   threaded operation (which is the common case) or on drivers which
   don't need it, e.g., currently NVidia binary blob, but possibly
   also the Catalyst blob in the future (unkown).

-> Screen for 64-Bit Octave on Linux rebuilt and tested with NVidia
   binary blob, to confirm there is no degradation for that setup
   which doesn't actually need the workaround.

-> Test on nouveau for active workaround pending.

The pain, when will it end?
Screen/Linux: Always poll-wait in PsychOSGetSwapCompletionTimestamp()

Not always of course, but also poll-wait if there is only 1 onscreen
window and all other requirements are fulfilled. We need to avoid a
blocking wait for swapbuffer completion, as we hold the display lock
during such a wait, so we'd block not only the (non-existent in the
single-window case) other graphics threads, but also the main thread
when executing X11 calls, e.g., GetMouse() queries.

This wasn't an issue before, but now that we lock the display lock, it
could cause some delays on the main thread even in the single window
case.
Rebuild Screen mex files for 32/64-Bit Octave and Matlab on Linux.

Finally incorporate all fixes for X11 display locking.
This one is probably as good as it gets.
Merge pull request #172 from kleinerm/master

Pull Linux display locking fixes.