Some Win32 API types are different fundamental types in the 32-bit and 64-bit
This problem is then further compounded by the fact that whilst both 32-bit
Cygwin and 32-bit MinGW use the ILP32 data model, 64-bit MinGW uses the LLP64
data model, but 64-bit Cygwin uses the LP64 data model.
This makes it impossible to write printf format specifiers which are correct for
all those targets, so we use some macros to provide the correct specifier for
the target.
LPARAM and WPARAM are integer types which can contain a pointer
LPARAM is long in ILP32 and long long in LLP64
WPARAM is unsigned int in ILP32 and unsigned long long in LLP64
Generally, these are just used to passs integer parameters, so for simplicity,
cast to int and use an int-compatible format
In the specific case of WM_CHANGECBCHAIN, they are used to pass HWND, so cast to
that type and print using an appropriate format.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Some Win32 API types are different fundamental types in the 32-bit and 64-bit
versions.
This problem is then further compounded by the fact that whilst both 32-bit
Cygwin and 32-bit MinGW use the ILP32 data model, 64-bit MinGW uses the LLP64
data model, but 64-bit Cygwin uses the LP64 data model.
This makes it impossible to write printf format specifiers which are correct for
all those targets
In the Win32 API, DWORD is an signed, 32-bit type. It is defined in terms of a
long, except in the LP64 data model, where it is an int.
It should always be safe to cast it to int and use %d.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Some Win32 API types are different fundamental types in the 32-bit and 64-bit
versions.
This problem is then further compounded by the fact that whilst both 32-bit
Cygwin and 32-bit MinGW use the ILP32 data model, 64-bit MinGW uses the LLP64
data model, but 64-bit Cygwin uses the LP64 data model.
This makes it impossible to write printf format specifiers which are correct for
all those targets
In the Win32 API, DWORD is an unsigned, 32-bit type. It is defined in terms of
an unsigned long, except in the LP64 data model, where it is an unsigned int.
It should always be safe to cast it to unsigned int and use %u or %x.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Window and Atom types derive from XID, which is always unsigned long in client
code, so use %ld format specifier
XTextProperty.nitems is of type unsigned long, so use %lu format specifier
ulReturnBytesLeft is of type unsigned long, so use %lu format specifier
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
remainingTime is computed as a long int, so use %ld format specifier
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
serverGeneration is of type unsigned long, so use %lu format specifier
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
struct winInfoRec.keyboard members are of type long, not type int
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
XID inside the server has type unsigned int (x86_64) or unsigned long (x86)
Follow the example of the rest of the server and cast to unsigned int and use
a %u or %x format.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
HWND derives from HANDLE, a pointer type, so we should use the %p format
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
The use of %d format for the DWORD return value of GetTickCount() isn't
portable, but it doesn't seem to be worth fixing it when this information isn't
very useful (and is redundant to the timestamping of log messages we now have)
Instead just remove these uses of GetTickCount()
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Link xwinclip with -lpthread to fix build for MinGW
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Report OS version in log
Report if WoW64 is in use
Manifest for compatbility with Windows versions, so we don't get lied to by GetVersionEx()
Also, make the description in the manifest a bit more generic
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Maybe a long time ago this made some kind of sense, but now there's no good
reason to ever use this, rather than the Shadow DirectDraw NonLocking engine.
Also remove screen private data members used by other removed engines.
Also remove no longer needed OS version check in winDetectSupportedEngines()
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Update man page to document pseudo-xinerama
v2: Make the use of PseudoramiXExtensionInit() match the prototype
v3: Update for nonsdk_extinit.h
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Turn on -hostintitle by default
Provide -nohostintitle to disable if needed
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Improve the parsing of the <proto> XML element
Include all text from the param element, in the order it appears in the xml
document, as part of the formal parameter declaration
This is needed to correctly handle the XML description added in svn r27498 of
glPathGlyphIndexRangeNV()'s baseAndCount parameter of type GLuint[2]
This fixes the way the parameter declaration is generated so it is in the
correct form 'GLuint baseAndCount_[2]' and not 'GLuint baseAndCount[2]_'
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Factor out duplicated code used in parsing of the <proto> XML element in the
code generator
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Nothing was using it and if anyone had they would've gotten a warning and
noticed that it doesn't actually work. Drop this, it has been unused for years.
Input ABI 22
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
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>
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>
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>
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>
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>
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f5 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>
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>
winmsgwindow.c:99:11: warning: variable ‘winClass’ set but not used [-Wunused-but-set-variable]
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
winprefslex.l:40:12: warning: redundant redeclaration of ‘yyparse’ [-Wredundant-decls]
winprefsyacc.h:130:5: note: previous declaration of ‘yyparse’ was here
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
winprefsyacc.y:257:3: warning: nested extern declaration of ‘yylineno’ [-Wnested-externs]
Promote yylineno declaration to file scope
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
winprefs.c:643:14: warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default]
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
winprefsyacc.y:174:5: warning: passing argument 1 of ‘AddMenuLine’ discards ‘const’ qualifier from pointer target type [enabled by default]
winprefsyacc.y:67:13: note: expected ‘char *’ but argument is of type ‘const char *’
winprefsyacc.y:174:5: warning: passing argument 3 of ‘AddMenuLine’ discards ‘const’ qualifier from pointer target type [enabled by default]
winprefsyacc.y:67:13: note: expected ‘char *’ but argument is of type ‘const char *’
winprefsyacc.y:175:5: warning: passing argument 3 of ‘AddMenuLine’ discards ‘const’ qualifier from pointer target type [enabled by default]
winprefsyacc.y:67:13: note: expected ‘char *’ but argument is of type ‘const char *’
winprefsyacc.y:178:5: warning: passing argument 3 of ‘AddMenuLine’ discards ‘const’ qualifier from pointer target type [enabled by default]
winprefsyacc.y:67:13: note: expected ‘char *’ but argument is of type ‘const char *’
winprefsyacc.c:1737:9: warning: passing argument 1 of ‘yyerror’ discards ‘const’ qualifier from pointer target type [enabled by default]
winprefsyacc.y:82:12: note: expected ‘char *’ but argument is of type ‘const char *’
winprefsyacc.c:1854:3: warning: passing argument 1 of ‘yyerror’ discards ‘const’ qualifier from pointer target type [enabled by default]
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
InitOutput.c:1032:19: warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default]
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
winmultiwindowicons.c:403:29: warning: passing argument 8 of ‘XGetWindowProperty’ from incompatible pointer type [enabled by default]
/usr/include/X11/Xlib.h:2688:12: note: expected ‘Atom *’ but argument is of type ‘long unsigned int *’
Looks like this has been wrong since I added it in 527cf131 :-(
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Fix various pieces of debug output, mainly under --enable-debug, which use a
"%08x" printf format for a pointer type. Use "%p" format for 64-bit portability.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
glext.h currently requires GL_GLEXT_PROTOTYPES in order to prototype
glCompressedTexImmage* functions
generated_gl_shim.c:2859:6: warning: no previous prototype for 'glCompressedTexImage3DARB' [-Wmissing-prototypes]
generated_gl_shim.c:2866:6: warning: no previous prototype for 'glCompressedTexImage2DARB' [-Wmissing-prototypes]
generated_gl_shim.c:2873:6: warning: no previous prototype for 'glCompressedTexImage1DARB' [-Wmissing-prototypes]
generated_gl_shim.c:2880:6: warning: no previous prototype for 'glCompressedTexSubImage3DARB' [-Wmissing-prototypes]
generated_gl_shim.c:2887:6: warning: no previous prototype for 'glCompressedTexSubImage2DARB' [-Wmissing-prototypes]
generated_gl_shim.c:2894:6: warning: no previous prototype for 'glCompressedTexSubImage1DARB' [-Wmissing-prototypes]
generated_gl_shim.c:2901:6: warning: no previous prototype for 'glGetCompressedTexImageARB' [-Wmissing-prototypes]
Also, explicitly prototype glXGetProcAddressARB(), as glx/glxdri*.c does, as
it's not practical to include glx.h here...
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
xevents.c: In function 'winClipboardInitMonitoredSelections':
xevents.c:129:5: error: 'for' loop initial declarations are only allowed in C99 mode
for (int i = 0; i < CLIP_NUM_SELECTIONS; ++i)
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
winshadddnl.c: In function ‘winRedrawScreenShadowDDNL’:
winshadddnl.c:991:9: error: ‘return’ with no value, in function returning non-void [-Werror=return-type]
Just wrong in 1c34e774
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Again, as the documentation says, "unsupported, obsolete".
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Adam Jackson <ajax@redhat.com>
As the man page says, "unsupported, experimental, and barely
functional". The last even minor updates to any of this were back in
2004, presumably it's not getting better any time soon.
This is also the only GC ops implementation in the tree that actually
falls all the way down to the spans routines for everything, so that's
pretty nice to be rid of.
v2: Fix stray break statement (Jon)
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Adam Jackson <ajax@redhat.com>
No modern driver pays attention to this. Presumably there existed
hardware once where you couldn't just read the right values out of the
CRTC.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Including any server header might define the macro _XSERVER64 on 64 bit
machines. That macro must _NOT_ be defined for Xlib client code, otherwise bad
things happen. So let's undef that macro if necessary.
Remove server directories from include path to ensure no server includes are
included
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
