New function for padding the buffer to full protocol units granularity:
If the current write position isn't at 4-byte granularity, it reserves
the remaining number of bytes (ie. writing zeros), in order to make the
next write align to 4-byte granularity again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
take way the extra scope / indention on the `if (nbox)` statement and
use `continue` instead.
Hint: for easier review, one can use `git diff -w` in order to suppress
the indention-only changes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
in preparation of upcoming new iterator macros, phase out
FOR_NSCREENS_FORWARD_SKIP, so we don't need an additional macro
for just the case where first screen is skipped.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of always accessing the global screens array, do it only once
and put it into a walk variable.
Also prepration for upcoming commits which are moving the looping logic
into a generic macro.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use a separate variable pWalkDraw for inside the loop, as it's got a
different purpose in here.
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>
The namespace config still has the "container" directive, which should have
been named "namespace". It's a leftover from the original working draft that
was named "container extension".
For the time being, keep backwards compatibility by allowing both tokens
"container" as well as "namespace" for the same directive. But consider the
old token as deprecated, it shouldn't be used anymore and might go away
in the near future.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's only caller already has the ScreenPtr, so it doesn't make any sense
passing in the screen number and let that function retrieve the pointer
on its own again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's only caller already has the ScreenPtr, so it doesn't make any sense
passing in the screen number and let that function retrieve the pointer
on its own again.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Practically all callers need to assign to a CARD32 field, so let it
directly compute and return as CARD32.
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>
Print out a warning when actually written payload length doesn't mactch
the previously computed one.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
As it's caller now has x_rpcbuf, we can use it here, instead of
meddling with pre-allocated buffer space directly via raw pointer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
As it's caller now has x_rpcbuf, we can use it here, instead of
meddling with pre-allocated buffer space directly via raw pointer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
As it's caller now has x_rpcbuf, we can use it here, instead of
meddling with pre-allocated buffer space directly via raw pointer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
As we now have x_rpcbuf, we can use it here, instead of meddling
with pre-allocated buffer space directly via raw pointer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
As it's caller now has x_rpcbuf, we can use it here, instead of
meddling with pre-allocated buffer space directly via raw pointer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
As it's caller now has x_rpcbuf, we can use it here, instead of
meddling with pre-allocated buffer space directly via raw pointer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
As it's caller now has x_rpcbuf_t, we can use it here, instead of
meddling with pre-allocated buffer space directly via raw pointer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The keymap assembly machinery is a horribly complicated machinery,
because often whole replies with variable sized payloads can be nested
into each other. It's time to use x_rpcbuf_t for that, but's is not an
easy thing to do and really a huge change - therefore doing this in small
and easy to digest step.
At first, let XkbAssembleMap() operate on a x_rpcbuf_t. But for now just
let it use the x_rpcbuf_t's raw buffer directly (because it's callees cant
work on this yet) - thus XkbAssembleMap() yet need to make enough room
in the buffer before calling in.
For the time being we're allocating far too much (because calculating
the actually need amount would be too complicated here) and having an
extra memcpy(). But it's just an intermediate step anyways - subsequent
commits will convert everything down the whole call chain into using
x_rpcbuf_t operations, so that extra overhead can be dropped again later.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* switch major version from 25.0 to 25
* make loader respect legacy 25.0 module dirs (to be removed in version
26)
Fixes: #646
Signed-off-by: callmetango <callmetango@users.noreply.github.com>
