Replace XDrawString8() by xcb_poly_text_8(), as well as XDrawString16()
by xcb_poly_text_16(). Some care needs to be taken to prepend the xTextElt
header before sending the request out.
GC operation handlers don't need to care about poly-strings or length
above 254, as this is already handled by their caller, doPolyText().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of going through mi machinery, just pass the ClearArea
request to the upstream window.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use xcb_create_colormap() and XFreeColormap() instead of XCreateColormap()
and XFreeColormap().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using xcb_shape_rectangles() and xcb_shape_mask() instead of Xlib's
XShapeCombineRegion() and XShapeCombineMask().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
No need to directly hard-crash the Xserver when strdup() fails, instead
try to handle the situation gracefully.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Little helper function for checking whether a resource XID
belongs to the server itself.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Retrieves the ClientPtr for the owner of given resource.
This way reducing the sites directly accessing clients[] array.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make it type-safe and a bit more obvious what it really does,
also adding some inline documentation. Since it's just some
bit shifting magic, it's qualified for inlining.
The CLIENT_ID() macro isn't used by any external modules, so the
new function doesn't need to be in a public header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Hide internals (drop the need to include windowstr.h), make it typesafe
as well as the naming easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
XID = 0 already is used as sign for error in several places,
so let's use that here, too.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The old PCCONS driver only seems to be used on minimal install disks and
cannot coexist with newer ones (at least that's the feedback I've gotten
from BSD community), so there's probably no practical use case for
supporting it in Xorg anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that the name clash on GC type between Xserver and xlib has been fixed,
there's no need to do the special renaming hack anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Both xlib as well as the Xserver use the same identifier "GC" for
different types. While on xlib it's just the numerical ID of a GC,
the xserver defines a struct for it by the same name. This is this
ugly and needs ridiculous hacks for Xserver code that needs xlib.
Easy to solve by just renaming the GC typedef to GCRec (consistent
with how we're naming other structs) and replacing GC* by GCPtr.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The function actually operates on ClientRec, so we can pass it in
directly, so it doesn't need to fetch it from clients[] array itself.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by anybody, neither Xserver nor drivers, so no need to
keep it around any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither Xserver nor drivers, so no need to keep it anymore.
According to git history, it had been introduced introduced in 2003 (*1),
but never called (inside the Xserver) - unclear whether it ever had been
actually used somewhere.
*1) 9508a382f8
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any driver for these cards anymore,
so no need for trying to probe them anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any sungt driver anymore, so no need for
trying to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any suncg12 driver anymore, so no need for
trying to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any suncg8 driver anymore, so no need for
trying to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any suncg4 driver anymore, so no need for
trying to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any suncg2 driver anymore, no need for trying
to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any sunbw2 driver anymore, so no need for trying
to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Enrico Weigelt, metux IT consult