<sys/filio.h>, <sys/sockio.h> and <sys/stropts.h> were included under
the grab-bag SVR4 / __SVR4 OS macro. Whether these headers exist is a
per-header question, so probe them directly:
- conf_data gains HAVE_SYS_FILIO_H / HAVE_SYS_SOCKIO_H /
HAVE_SYS_STROPTS_H via cc.has_header (alongside the other
HAVE_SYS_*_H checks),
- os/Xtranssock.c gates <sys/filio.h> on HAVE_SYS_FILIO_H,
- os/access.c gates <sys/sockio.h> on HAVE_SYS_SOCKIO_H and
<sys/stropts.h> on HAVE_SYS_STROPTS_H (split into independent guards
since they are now independent probes).
<sys/stropts.h> is SVR4/Solaris-only, so its check is exactly
equivalent to the old SVR4 guard. <sys/filio.h> and <sys/sockio.h> also
exist on the BSDs, so they are now correctly included there too (they
provide the FIO*/SIOC* ioctls and are idempotent — the BSD <sys/ioctl.h>
already pulls them in), which is the intended "include it where it
exists" behaviour rather than "only on SVR4".
Verified: Linux -Dwerror=true build gets all three as #undef (none of
the headers exist there, identical to SVR4 being undefined) and links
Xvfb and Xnest cleanly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The SysV `struct termio` type is used nowhere in the tree — the only
`termio` occurrence is the unrelated `#include <termio.h>` in the
SVR4/Sun block — so this BSD-only alias mapping `termio` to `termios`
under `#ifdef CSRG_BASED` is dead code and can be removed.
The rest of the `#ifdef CSRG_BASED` block is left intact: it is a
legitimate structural BSD-header block, to be dealt with in a later
xf86_OSlib.h restructure.
The CSRG_BASED block isn't compiled on Linux; a `-Dwerror=true` Linux
build links Xvfb and Xnest cleanly, confirming no accidental damage.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Whether <sys/param.h> is available is a header question, not an
OS-family question. Both os/connection.c and os/access.c included it
under `#ifdef CSRG_BASED` (i.e. "is this a BSD-derived system or
Darwin?") — a grab-bag OS macro standing in for the concrete fact that
actually matters. Replace it with a proper feature check.
Add HAVE_SYS_PARAM_H via cc.has_header('sys/param.h') to conf_data
(alongside the other HAVE_SYS_*_H probes) and switch both includes to
it. This is behaviour-preserving:
- On the BSD/Darwin systems where CSRG_BASED was set, sys/param.h
exists, so the header is still included.
- In os/access.c the inner `#if (BSD >= 199103)` guard is unchanged:
BSD is only defined by sys/param.h itself (on real BSD), so on other
platforms it stays undefined and VARIABLE_IFREQ is not defined —
exactly as before.
- On platforms that always have sys/param.h (e.g. glibc/Linux) the
header is now also included, which is harmless.
Verified: Linux build with -Dwerror=true configures and links Xvfb and
Xnest cleanly (no MIN/MAX or other redefinition from the widened
include).
First step of replacing the tree's grab-bag OS-family #ifdefs
(CSRG_BASED, SVR4, ...) with concrete, meson-detectable feature flags.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The xf86Info.consType field and the BSD console-driver-type constants
(PCCONS/SYSCONS/PCVT/WSCONS/...) are the BSD console machinery consumed
by hw/xfree86/os-support/bsd/console_*.c and bsd_VTsw.c. They were
gated on the opaque grab-bag macro CSRG_BASED ("Computer Systems
Research Group", i.e. BSD-derived) OR'd with __FreeBSD_kernel__.
Introduce a self-documenting meson flag CONFIG_BSD_CONSOLE (following
the existing CONFIG_WSCONS/CONFIG_UDEV/... convention) set to exactly
`csrg_based or host_machine.system() == 'kfreebsd'` — i.e. the same set
of platforms the old `CSRG_BASED || __FreeBSD_kernel__` guard matched —
and use it at all three sites (struct field, constants, initializer).
Behaviour / ABI:
- The flag is true on precisely the same platforms as before, so the
xf86InfoRec layout is unchanged everywhere. On Linux (and every
non-BSD target) CONFIG_BSD_CONSOLE is undefined just as CSRG_BASED
was, so consType stays absent and the struct offsets — hence the
driver ABI, incl. the nvidia blob — are untouched.
- Fixes a latent inconsistency on GNU/kFreeBSD: the struct field was
present there (via __FreeBSD_kernel__) but xf86Globals.c initialised
.consType only under #ifdef CSRG_BASED, so it defaulted to 0 instead
of -1. Both are now driven by the single CONFIG_BSD_CONSOLE flag, so
field presence and initialiser always agree.
Verified: Linux -Dwerror=true build configures (dix-config.h gets
`#undef CONFIG_BSD_CONSOLE`) and links Xorg cleanly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
include/dix.h defined ARRAY_SIZE() unconditionally. On platforms whose
system headers already provide it — notably illumos/Solaris
<sys/sysmacros.h> — that is a redefinition, fatal under -Werror
("ARRAY_SIZE redefined"). Wrap it in #ifndef, matching what
Xext/dri2/pci_ids/pci_id_driver_map.h already does, so any translation
unit that pulls in a system ARRAY_SIZE before dix.h keeps building.
(Robustness fix: the concrete xf86bigfont Solaris break that exposed this
is separately fixed by dropping its <sys/sysmacros.h> include, but dix.h
should not be fragile for the next such file.)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
GLYPHPADBYTES used to be a machine-dependent knob in <servermd.h>,
tunable per platform for the old mfb/cfb glyph blitters. Those are
long gone and the value has been fixed at 4 for over a decade; the
remaining "!= 4" code paths were just dropped (a09755b66), and
GLYPHWIDTHBYTESPADDED() now hardwires the 4-byte row pad directly.
That left the server-side glXUseXFont() implementation as the single
remaining user, where it is handed to GL_UNPACK_ALIGNMENT so OpenGL
steps to each next glyph row on the same boundary X padded them to.
Since it is no longer machine-dependent and nothing else references
it, there is no reason to keep it in the public SDK header: move the
definition next to its lone use in Xext/glx/xfont.c, with a comment
explaining what it is and why it must match GLYPHWIDTHBYTESPADDED().
No functional change.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
sizes can't have negative numbers, so use the size_t here.
Also having to fix up lots of callers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's always defined to 4, for over a decade now, so no extra case
checks needed anymore.
See: 17c3347f14
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add a buildtime-selectable meson option 'debug_writetoclient' that logs
every call going through the exported WriteToClient() frontend, to help
track down which (out-of-tree / not-yet-converted) callers still use the
legacy public entry point instead of dixWriteToClient().
- none (default): no logging, the frontend stays a plain tail call
- caller: log client/count plus the immediate caller (return address,
resolved to a symbol name via dladdr() when available)
- backtrace: log client/count plus a full xorg_backtrace() stack
The option maps to CONFIG_DEBUG_WRITETOCLIENT[_BACKTRACE] in dix-config.h.
Internal reply/event paths use dixWriteToClient() directly and are not
affected by this logging.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
PR: https://github.com/X11Libre/xserver/pull/3162
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Move the actual body of WriteToClient() into a new internal worker
dixWriteToClient() and turn WriteToClient() into a thin exported
frontend that just delegates to it.
This separates the two roles the function had: the exported, legacy
entry point kept for ABI compatibility with out-of-tree drivers/modules,
and the worker used by all in-tree reply/event paths. In-tree callers
will be moved over to dixWriteToClient() in the following commits, which
also lets the frontend be instrumented later without affecting internal
paths.
dixWriteToClient() is declared in the private os/io_priv.h but still
exported (_X_EXPORT), since in-tree modules that may be built as separate
shared objects (e.g. GLX) need to link against it.
The xi1/xi2 protocol unit tests intercept the reply path via
-Wl,-wrap,WriteToClient. As the in-tree reply path moves onto
dixWriteToClient(), retarget the linker wrap (and the WRAP_FUNCTION /
wrapped_* references) to dixWriteToClient(); this also covers calls that
still go through the WriteToClient() frontend, since it funnels into the
same worker.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
PR: https://github.com/X11Libre/xserver/pull/3162
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Match the implementation signatures. os.h is an installed public SDK
header that may be included by C++ or pre-C99 consumers where the bare
'restrict' keyword does not compile, so use the portable _X_RESTRICT_KYWD
macro instead (it expands to nothing where restrict is unavailable, and
deliberately avoids 'restrict' under C++ to work around a g++ issue on
Solaris).
Signed-off-by: Victor Lev <levvictor123@gmail.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Simplify saveSet handling by just using trivial `struct xorg_list` instead
of complicated dynamically resized array. Common operations like insert or
remove are much simpler using lists instead of arrays.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Most xorg_list operations already tolerate a list head that was merely
zero-initialized (next == prev == NULL) instead of run through
xorg_list_init(): xorg_list_add()/xorg_list_append() auto-init via
__xorg_list_autoinit(), and xorg_list_for_each_entry(), xorg_list_is_empty()
and xorg_list_present() guard against a NULL head->next.
Two paths were still missed, so a head embedded in a calloc()'d struct could
crash before anything was ever added to it:
- xorg_list_for_each_entry_safe() guarded its loop *condition* with
(head)->next != NULL, but its init clause unconditionally computed
tmp = container_of(pos->member.next, ...). On a zeroed head, pos resolves
to container_of(NULL) and reading pos->member.next dereferences address 0,
crashing before the guard is evaluated. Seed tmp from
(head)->next ? pos->member.next : NULL so an empty/zeroed list iterates
zero times without dereferencing anything.
- xorg_list_del() dereferenced entry->prev/entry->next directly, so resetting
a zeroed head (the documented "reset to empty list" use) would NULL-deref.
Auto-init it first, consistent with xorg_list_add()/xorg_list_append().
With these, a zero-initialized xorg_list head behaves as a valid empty list
across the whole API, so an embedded list head no longer strictly requires an
explicit xorg_list_init() call to be safe.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since no drivers are compiled against this anymore, and the mioverlay.c
functions only dummies just to satisfy proprietary Nvidia driver's
symbol dependencies, this header isn't needed anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Initally we used value of DRM_FORMAT_ARGB8888, but it seems than
xf86-video-ati has established other value for years. So, change it to
well established one.
Because we define a different values, this breaks compilation of xf86-video-ati.
I am unsure, who is right in this situation, but I guess better to use
an established value, to make AMD xorg driver compile.
I do not aware about any of the side effects of this change.
Fixes: 15412e78c8 - glamor: xv: add rgba32 format
Signed-off-by: Konstantin <ria.freelander@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1321>
First step of untwisting xfixes: move the small private data structure
directly into ScreenRec - this is just the head pointer for the (per
client) cursor hide counters and the wrapped DisplayCursor() vector.
This functionality is planned to be moved into DIX later.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Don't waste time probing egl extenions with meson.
libepoxy (and libglvnd) already have macros defined for
various EGL extensions that the gl library knows about.
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
Before this, when we wanted to import pixmaps from dma bufs,
we were importing a gbm bo from dma bufs, exporting the
gbm bo as dmabufs, importing an EGLImageKHR from those
dmabufs, and finally creating a pixmap from the EGLImageKHR.
Now, we just import the image and create a pixmap from it.
See: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2057#note_3442757
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
Use getrandom() as the preferred source of random data when available,
getrandom() works in chroots and containers without the random device
node.
Note this is a build-time preference, not a runtime preference.
Assisted-by: Claude:claude-claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2200>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
As of last commit, all of glamor_egl ix xf86 agnostic, so adjust the
includes and drop the GLAMOR_FOR_XORG instances.
Note the macro is still used for glamor_xv_init() which pulls xf86.
v2: Drop GLAMOR_FOR_XORG guards (Michel Dänzer)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/235>
Add a clear marker telling the border line of which fields drivers
are allowed to touch (except for in-tree drivers) - anything below
is NOT part of ABI anymore and can change anytime.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
`glamor_egl_init2` is now another function that can be used by xf86 drivers
Currently, all default glamor egl caps are either all set or all unset.
In the future, I'm planning to make it so that systems where
only some glamor egl caps can be enabled will have them enabled,
even if more advanced caps are unavailable.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
On MacOS we're getting tons of warnings, because Xdefs.h also defining
this type. In the longer run we should check whether to include
Xdefs.h at all, but for the time being just doing a quick workaround.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The structs from closure.h and closestr.h are only used inside dixfonts.c,
thus no need to have them scattered around several headers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The recent development versions of xorgxrdp require these 5 glamor_*
functions that were made private in the past:
glamor_fds_from_pixmap: Made private in ea232c7
glamor_pixmap_from_fds: Made private in 81c1479
glamor_get_formats: Made private in 6f6aab8
glamor_get_modifiers: Made private in 0644764
glamor_get_drawable_modifiers: Made private in 800ab10
Exporting them again to make xorgxrdp compilable with XLibre.
Signed-off-by: b-aaz <b-aazbsd@proton.me>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's only used by glamor internally, on error pathes where the pixmap
has been created only partially and something went wrong.
Drivers don't call this function.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Apparently the enum values cannot be checked during preprocessor phase.
Fix it with checking gbm version using meson and defining additional
symbols which are visible during compile time.
Signed-off-by: Tautvis <gtautvis@gmail.com>
This version of the spec (latest as of 27.12.2021) adds a variable
`$XDG_STATE_HOME` that may be used for log files, as described:
```
...
$XDG_STATE_HOME defines the base directory relative to which user-specific
state files should be stored. If $XDG_STATE_HOME is either not set or
empty, a default equal to $HOME/.local/state should be used.
The $XDG_STATE_HOME contains state data that should persist between
(application) restarts, but that is not important or portable enough to
the user that it should be stored in $XDG_DATA_HOME. It may contain:
actions history (logs, history, recently used files, …)
...
```
- https://specifications.freedesktop.org/basedir/0.8/
Signed-off-by: Edênis Freindorfer Azevedo <edenisfa@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/836>
It will take some time for a new libpciaccess to be released and
even then bumping the dependency for libpciaccess isn't attractive.
If an older libpciaccess is used just add a static inline define.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2038>
