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>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs this function for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs this function for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs this function for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs this function for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs this function for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs this function for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs this function for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs this function for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
NVidia's proprietary driver does it's own randr implementation (why ?)
and needs those fields for this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since most of the extension init logic (and on/off switches for them)
is driven from miext, this seems the appropriate place for the header.
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>
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>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The ‘RRCrtcNotify() and RRCrtcSet() functions are exported, so there's chance
that a buggy driver could call them with NULL parameter, leading to segfault.
Those are hard to trace, so it's better having a BUG_* check here.
| ../randr/rrcrtc.c: In function ‘RRCrtcNotify’:
| ../randr/rrcrtc.c:187:5: warning: use of NULL ‘outputs’ where non-null expected [CWE-476] [-Wanalyzer-null-argument]
| 187 | memcpy(crtc->outputs, outputs, numOutputs * sizeof(RROutputPtr));
| | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ../randr/rrcrtc.c: In function ‘RRCrtcSet’:
| ../randr/rrcrtc.c:742:20: warning: dereference of NULL ‘outputs’ [CWE-476] [-Wanalyzer-null-dereference]
| 742 | if (outputs[o]) {
| | ~~~~~~~^~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
If there's no data to send, the whole reply payload can be skipped entirely.
This can also ease the whole code flow, and we don't need to rely on the
individual copy loops never trying to dereference a NULL pointer.
(what the analyzer can't proof). Also scoping several some variables that
are only used when there actually is data to send.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
If there's no data to send, the whole reply payload can be skipped entirely.
This can also ease the whole code flow, and we don't need to rely on the
individual copy loops never trying to dereference a NULL pointer.
(what the analyzer can't proof). Also scoping several some variables that
are only used when there actually is data to send.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Moving payload buffer assembly right into the same branch where the buffer is
allocated, so making the whole code flow easier to understand. Also moving the
byteswap there (when the fields should still be in CPU cache), instead of having
some callback doing it much later, so even more simplication.
As a nice by-product, that's also reducing some analyzer noise.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The code can be much simpler by just using CopySwap32Write().
And we also don't need the callback in WriteSwappedDataToClient(),
just call the corresponding write function directly.
This also makes some analyzer warnings go away.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
