hw/xwin: Remove some redundant clipboard externs, now defined in winglobals.h

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
hw/xwin: In SelectionNotify, delete the property containing returned data after we have retrieved it

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
hw/xwin: In SelectionNotify, don't pointlessly retrieve just the size of the property

Don't pointlessly retrieve just the size of the property, if we are then going
to assume we can retrieve the whole property in one request anyhow...

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts

See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html

It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.

If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.

It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.

The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.

So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.

Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.

v2: Fix compilation with -Werror=declaration-after-statement

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
hw/xwin: Add controls for enabling/disabling monitoring of PRIMARY selection

xwinclip: Add -noprimary option
Xwin: Add -primary and -noprimary options and tray-menu control

v2:
Use Bool type for fPrimarySelection
Add -noprimary to usage message
Fix indentation in hw/xwin/winwndproc.c

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
hw/xwin: Improve reliability of clipboard X->Windows pastes

Sometimes, particularly with large clipboard pastes to Windows, we could end up
waiting for the timeout to expire, rather than pasting the data.

Various changes to improve reliability:

1. Use XFlush() not XSync() in winProcessXEventsTimeout().

It makes no sense to ensure we have received replies to outstanding requests if
we are going to wait for them using select()

2. Add XFlush() to winClipboardProc()

Make sure we have sent any requests before we wait using select()

3. Don't use FD_ISSET() to check which fd is ready

This looks like a Cygwin select() bug in that it sometimes returns 0 with an
empty fd set before the timeout expires, but a fd appears to be ready.

Add select() return value to debug output when we are warning that this has
happened.

4. Drain event queues before entering select()

Unconditionally drain event queues before entering select().  This seems to be
the recommended way of writing select() and X event processing loops.

winClipboardFlushXEvents() checks using XPending(), and
winClipboardFlushWindowsMessageQueue() checks using PeekMessage() so this is
safe against blocking, but means that may not need to enter select() at all
sometimes.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
hw/xwin: Fix clipboard thread restart

It seems that the clipboard thread restart mechanism has been broken for a
while, which can be demonstrated using XDMCP with KDM (e.g. to a Kubutunu 12.04
host)

KDM kills all attached clients, including the clipboard integration client,
which restarts, but then exits on WM_QUIT.

Using PostQuitMessage() in WM_DESTROY is unhelpful, as we may not actually be
quitting the thread, if we just destroyed the window because the clipboard
thread is about to retry, because he WM_QUIT message sticks around, and is
noticed the next time we look at the window message queue and confuses us into
thinking we need to quit.

Sending a WM_DESTROY is apparently never correct anyhow, see [1]

So:

1/ Use DestroyWindow() to destroy the clipboard messaging window when cleaning
up for retry or exit in winClipboardProc (the clipboard thread main proc)

2/ Send a special WM_WM_QUIT message in winClipboardWindowDestroy() from the X
server thread when the X server is resetting.

3/ When processing that WM_WM_QUIT message in the clipboard thread, cause the
clipboard window to PostQuitMessage(), which causes the clipboard thread to
exit.

[1] http://blogs.msdn.com/b/oldnewthing/archive/2011/09/26/10216420.aspx

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
hw/xwin: Fix hang on shutdown when we own the clipboard.

If we are the clipboard owner when we are shutdown, we recieve a
WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
available to other applications.  Unfortunately, this is far too late to do
anything useful with, as the server is waiting for the clipboard thread to exit,
and so can't process requests to convert clipboard contents.

Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
WM_RENDERALLFORMATS has ever worked usefully, in any case).

(To make this work, I guess we would need to rearrange the way shutdown works
completely: first synchronously stop the clipboard, then stop the X server)

We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
clipboard formats have changed (as ones which haven't been rendered are now
removed), but the clipboard owner is now the system, not us, which we have to
arrange to ignore.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
hw/xwin: Don't allocate one wchar_t too much for unicode text placed on the Windows clipboard

The count of wchar_t returned by MultiByteToWideChar() includes the terminating
null character, so don't add one to it.

Also, reduce the scope of various length variables

Signed-off-by: Colin Harrison <colin.harrison@virgin.net>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Revert "glx: Simplify glXDestroyContext"

This reverts commit 7f5adf73a0f9a951a6df201532b4031d38054369.

This seems to miss the whole point of the idExists flag, as it makes the
lifetime of that being true the same as the lifetime of the Context resource.

The previously current context tag is always given in a MakeContextCurrent
request, even if that context tag is no longer valid (for example, the context
has been deleted), so this leads to BadContextTag errors.

See fd.o bug #30089 for the makecurrenttest.c testcase, and some discussion of
previous manifestations of this bug.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
glx: Flush context which is being made non-current due to drawable going away

Some sequences of glean tests fail with GLXBadCurrentWindow when using indirect
rendering, e.g. glean -t 'fpexceptions getString'.

Flush a context which is being made non-current due to the drawable on which is
it is current going away.  Waiting until another context is made current is too
late, as the drawable no longer exists.

v2: Rewrite for direct GL dispatch

v3: Inline FlushContext(), doesn't need to be a separate function

e.g. LIBGL_ALWAYS_INDIRECT=1  ./glean -r results -o --quick -t "fpexceptions
getString" fails with a BadContextTag error.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
glx: Fix crash when a client exits without deleting GL contexts

With the previous patches applied, we now have crash due to use-after-free when
a client exits without deleting all it's GL contexts

On client exit, CloseDownClient first calls glxClientCallback() with
ClientStateGone, which calls __glXFreeContext() directly.

Subsequently CloseDownClient() frees all the clients resources, which leads to
ContextGone() being called for a context resource where the context has already
been freed.

Fix this by modifiying glxClientCallback() to free the context resource.

Also make __glXFreeContext() static, as calling it directly leads to this
problem, instead the context resource should be released.

With the previous patches applied, this can be demonstrated with e.g. glxinfo,
which doesn't delete it's context before exit.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Merge remote-tracking branch 'jturney/master'
Merge remote-tracking branch 'jturney/indirect-glx-fixes'