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>
With this, X servers don't have to parse this option separately,
and can just use it after including dix-config.h
Linux kdrive servers (currently Xfbdev only) now support logging.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
Signed-off-by: default avatarDiego Viola <diego.viola@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2138>
---------------------------------------------------------------------------
One of the spelling errors was moved to another file and fixed there
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
Signed-off-by: Diego Viola <diego.viola@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2134>
----------------------------------------------------------------------------
This commit is the result of `git apply commit.diff --reject`
applied on e8f452231267c82078fe does not
apply to Xlibre
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
