Upcoming patches will need to retieve GC's XIDs on the upstream connection.
Moving this out into separate .c file, in order to not creating more
dependencies on Xlib headers, which we wanna get rid of.
For now, looking at the Xlib GC structure, attached to our DDX GCs.
When all users of the Xlib GC have gone (ie. moved all consumers to xcb),
we'll create the GC via xcb directly, thus replacing the Xlib GC struct
by XID - the interface of this helper will remain the same.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Fetching the setup data from xcb instead of Xlib, storing in our own struct,
holding all information needed for one particular upstream connection.
For now, there's only one, but future multi-upstream implementation will
change this to an array (and storing pointers to particular upstream in
various places).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since we're not indirectly writing via FILE anymore, this option has
become meaningless: it meant flushing out our in-process buffer to
the kernel, but we're now doing direct write() calls anyways.
xf86 still accepts the "flush" config file flag for backwards compatibility,
but it hasn't any practical meaning anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These functions are entry points of the DDX (or stubs thereof), not supposed
to be called by any drivers, so no need to keep them exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These aren't used by any drivers/modules, and it doesn't seem make much
sense doing so, thus no need to keep them exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external drivers/modules, so no need to keep it public.
Since modesetting is using it, still needs _X_EXPORT, as long as it's
a module.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
../hw/xwin/InitOutput.c:89:2: warning: redundant redeclaration of ‘winValidateArgs’ [-Wredundant-decls]
89 | winValidateArgs(void);
| ^~~~~~~~~~~~~~~
In file included from ../hw/xwin/InitOutput.c:35:
../hw/xwin/win.h:1008:1: note: previous declaration of ‘winValidateArgs’ was here
1008 | winValidateArgs(void);
| ^~~~~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external drivers, so no need to keep it public.
Also add some type-safety by implementing it as static inline function.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Drop a several includes of colormapst where we don't actually
need something from that file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
a) an internal function that's not used by any drivers
b) conflicting with function/define of same name on win32
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
> ../hw/xwin/winscrinit.c: In function ‘winFinishScreenInitFB’:
> ../hw/xwin/winscrinit.c:381:18: error: ‘struct _Screen’ has no member named ‘CreateWindowA’; did you mean ‘CreateWindow’?
> 381 | pScreen->CreateWindow = winCreateWindowRootless;
> | ^~~~~~~~~~~~
> ../hw/xwin/winscrinit.c:405:18: error: ‘struct _Screen’ has no member named ‘CreateWindowA’; did you mean ‘CreateWindow’?
> 405 | pScreen->CreateWindow = winCreateWindowMultiWindow;
> | ^~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
> ../hw/xwin/winclipboard/xevents.c: In function ‘winClipboardSelectionNotifyData.constprop’:
> ../hw/xwin/winclipboard/xevents.c:313:23: warning: ‘codepage’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> 313 | int iUnicodeLen = MultiByteToWideChar(codepage, 0,
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 314 | pszReturnData, -1, NULL, 0);
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ../hw/xwin/winclipboard/xevents.c: In function ‘winClipboardFlushXEvents’:
> ../hw/xwin/winclipboard/xevents.c:550:35: warning: ‘codepage’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> 550 | int iConvertDataLen = WideCharToMultiByte(codepage, 0,
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 551 | (LPCWSTR) pszGlobalData, -1,
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 552 | NULL, 0, NULL, NULL);
> | ~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Windows headers are pretty nitpicking about include order:
> In file included from /usr/i686-w64-mingw32/include/X11/Xwinsock.h:57,
> from /usr/i686-w64-mingw32/include/xcb/xcb_windefs.h:34,
> from /usr/i686-w64-mingw32/include/xcb/xcb.h:41,
> from ../hw/xwin/winmultiwindowicons.c:43:
> /usr/share/mingw-w64/include/winsock2.h:15:2: warning: #warning Please include winsock2.h before windows.h [-Wcpp]
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Enrico Weigelt, metux IT consult