It's always present (and wont go away), so no need to ifdef on it.
Still keeping the symbols, until we're sure no drivers still depending
on it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Drop the -reset flag, so Xserver now either simply continues (w/o going
through internal reset) when last client disconnected or terminates
when -terminate is given.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of directly accessing the global screenInfo.screens[] array,
let everybody go through a little inline helper. This one also checks
for array bounds - if the screen doesn't exist, return NULL.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, so no need to keep it in public SDK.
Since it's not used by any drivers, effectively no ABI change, so
can be safely done within ABI-25.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
iterating over screen list via lambda-esque macros calls like this
DIX_FOR_EACH_SCREEN({
do_something
});
withing the body, the iterator variables `walkScreenIdx` and `walkScreen`
are defined and can be directly used (read-only). the code inside the body
is running in a separate scope.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have whole extra functions for just a few LoC, and in the
future the whole thing will become more simplified by generic macros.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have whole extra functions for just a few LoC, and in the
future the whole thing will become more simplified by generic macros.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Don't rely on this file just being included indirectly by somebody else
just by accident.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Move functions/macros dealing with request parsing or reply assembly/write
out of the big dix_priv.h into their own headers. This new header will also
get more of those function/macros soon (yet still in the pipeline).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The xXineramaScreenInfo payload type has the same definition as xRectangle,
so we can just use x_rpcbuf_write_rect() for those.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
When iterating screen lists, consistently use the same variable name
`walkScreenIdx` for holding current screen index everywhere.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The macro will automatically return BadAlloc if the buffer is broken,
otherwise Success. Thus, we don't need extra prior rpcbuf check.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use x_rpcbuf_t for reply payload assembly and X_SEND_REPLY_WITH_RPCBUF()
for sending it all out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use x_rpcbuf_t for request assembly and X_SEND_REPLY_WITH_RPCBUF()
for finally sending out everything together.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
When iterating screen lists, consistently use the same variable name
`walkScreen` for holding current screen pointer everywhere.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The global (exported) serverGeneration field is `unsigned long`, while
many other places copy it and compare it two other integer types, eg.
plain `int` (which is signed). Even if it's unlikely ever reaching such
high number of generations that it will ever make trouble, it's still
a good idea to clean this up and use the same type everywhere.
For clearity, introducing a typedef `x_server_generation_t` which is
used everywhere, instead of raw `unsigned long`.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use x_rpcbuf_t for reply payload assembly and byte-swap
* do byte-swap of header fields explicitly instead of cryptic functions
* drop extra length computation
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use x_rpcbuf_t for reply payload assembly and byte-swap
* do byte-swap of header fields explicitly instead of cryptic functions
* drop extra length computation
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use x_rpcbuf_t for reply payload assembly and byte-swap
* do byte-swap of header fields explicitly instead of cryptic functions
* drop extra length computation
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use x_rpcbuf_t for reply payload assembly and byte-swap
* do byte-swap of header fields explicitly instead of cryptic functions
* drop extra length computation
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use x_rpcbuf_t for reply payload assembly and byte-swap
* do byte-swap of header fields explicitly instead of cryptic functions
* drop extra length computation
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of using our own Use x_rpcbuf_t for assembling and
byte-swapping the reply payload.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The commit 30cec78 incorrectly changed RRInitPrimeSyncProps to not
create the atom if it doesn't exist.
Signed-off-by: dec05eba <dec05eba@protonmail.com>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header needs to be included in all sources at the very top anyways,
so no need to do it in other headers, too.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use the new shortcut helper for cases where we need to check
whether an atom exists and retrieve it's ID.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
X has various ways to deal with DPI but all of the current methods have
some drawback (single global value, manually calculating from physical
dimensions, etc.) What is lacking is a simple value per output that
users and applications can use to communicate desired scaling values.
Fortunately, a generic output property mechanism already exists. And
they already send events whenever there is a change. So all we have to
do is make an "official" property for people to agree on and enshrine
it. In that case, all outputs can just always have the DPI property set
to something. In most cases, this will be 96 (the default), but one
could use the -dpi argument when launching or and that value will be
used instead. The intention is that 96 is the base that is equivalent to
1x scaling. i.e. 192 would be 2x, 144 would be 1.5x and so on. xrandr or
any other utility can modify this property at any time and applications
can choose to use the number in a way that makes sense.
Closes#208. Credit to @dec05eba for essentially coming up with the idea
of using output properties.
Signed-off-by: Dudemanguy <random342@airmail.cc>
If a device property is going to be updated, but failing due
the new value being too big, the buffer isn't freed.
Also compacting the logic for this into small inline function.
Fixes: 948630fa42
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
A client might send a request causing an integer overflow when computing
the total size to allocate in RRChangeProviderProperty().
To avoid the issue, check that total length in bytes won't exceed the
maximum integer value.
CVE-2025-49180
This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2024>
