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 reply payload assembly and send it out via
X_SEND_REPLY_WITH_RPCBUF() macro.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The PixmapRec is already calloc()'ed, so no need for additional zero-writes
into individual fields. This also removes some unncessary #ifdefs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Forgotten to remove an obsolete comment when ancient DGA-1.0 was removed.
Fixes: 4615067264
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
size_t is unsigned, but might have different sizes depending on CPU arch,
so casting it to unsigned long, so we can safely use %ld.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This is a relic from the 90s, giving really unsafe direct framebuffer
acccess. The very few known clients ever using this already been ported
to DGA 2.0 decades ago. The code is heavily tied to 32 bit architectures
anyways, so unlikely to even work on non-acient hardware.
So, without any clients left, there's no need to keep, let alone (try to)
repair that old cruft.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The Xi protocol has some pretty unclean design aspect: instead of adding a
new sub-request type, version 2.2 introduced a different request structure
with some extra fields. So depending on which version the client has selected,
we need to operate on separate structs.
In the current implementation, there's a unclean hack by using the extended
structure and only accessing the extra fields when using v2.2 or above.
Even though this works, it's making the code unnecessarily complicated and
blocking the use if canonical request parsing macros (which are coming with
subsequent commits).
Thus, it's time to clean it up and only use the exactly correct structs
in the two different cases. The trick is just branching by version and pick
out the the interesting values from the corresponding structs, so they can
later be used in the (mostly) version independent part.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since everything's running via Writev() methods now, the now unused Write()
methods can all be dropped.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that all WriteV() methods are operating on single buffer instead ofiovec's,
we don't need the complicated _XSERVTransWriteV() anymore, but instead can
write directly to the socket/fd.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since they're only called with a one-element iovec, we can use a single
buffer pointer straight away, thus making it quite the same as the old
Write() methods.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
_XSERVTransWrite() is only intended as frontend, for xtrans consumers to
call in here. And upcoming commits will change that function to call the
Writev() method instead of Write(), so we would end up in infinite
recursing if we'd still it it here.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Refactor _XSERVTransWriteV() to call write() on Unix and instead drop
the WRITEV() macro.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use x_rpcbuf_t also for writing individual fields and so let it also
do the byte-swapping.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Anonymous structs and unions are a GNUism, violating C standard, thus
better not using it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
For better readability, declare the variables only where they're used,
and try to scope them, instead of declaring them all on the very top.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
They are all disabled for now, build options for enabling them
will be added when Xfbdev is added.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
At this point just use it as allocator, so we can use the
X_SEND_REPLY_WITH_RPCBUF() macro for final sending.
Follow-up commits will change the whole call stack to operate on
x_rpcbuf_t directly, so it's also doing the byte-swap for us.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use x_rpcbuf_t for reply payload assembly, so we can uniformly use the
X_SEND_REPLY_WITH_RPCBUF() macro for final write out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Fix pedantic warnings:
> ../include/os.h:144:71: warning: ISO C does not allow extra ‘;’ outside of a function [-Wpedantic]
> 144 | XNFalloc(unsigned long /*amount */ ) __attribute__((returns_nonnull));;
> ../include/os.h:158:76: warning: ISO C does not allow extra ‘;’ outside of a function [-Wpedantic]
> 158 | XNFcallocarray(size_t nmemb, size_t size) __attribute__((returns_nonnull));;
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The code below the `out` label is using the rpcbuf variable, but we have
a jump site before the variable is declared. It had been overlooked, because
for yet unknown reasons the compiler doesn't complain at all about this.
We could assume that it at least moves the stack allocation upwards
(always could even happen even on function entry), but we don't know whether
the memory is already unitialized.
So, to be on safe-side, move the declaration upwards, before the first
jump site.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
