When using struct initializers, all fields not set explicitly are zero.
Also no need to swap fields that are known to be zero.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The `majorVersion` and `minorVersion` fields are CARD16, thus need to be swapped.
OTOH, the lengths field is zero anyways, so no need to swap it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This file became obsolete with 33350ef8ff, but was forgotten to
be removed.
Fixes: 33350ef8ff
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These dispatcher functions are much more complex than they're usually are
(just switch/case statement). Bring them in line with the standard scheme
used in the Xserver, so further steps become easier.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The original intention was negotiating versions before any further requests
can be processed, so requests that might become incompatible in future versions
still can be dispatched correctly. But practically that's never been the case:
there's just one major version, and it's unlikely that a new *major* version
(that might be incompatible with the current one, using same request codes for
different things) will come in the forseeable future.
So this extra logic isn't practically needed and just complicates dispatching.
Dropping it clears the road for further simplification of the dispatcher.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The diffenciation between Xinerama and single screen version is by tweaking
call vectors unncessarily complicated: it the only reason why these are
needed in the first place. Finally, it's just about one function, so it's
much easier just branching off in ProcDamageCreate() in case of Xinerama
is enabled.
This also clears the road for further simplification of the dispatcher.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Most of the complexity here isn't needed at all. It can be really trivial,
since we just have one operation anyways.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Move extra complexity out of the dispatch functions, so they're
really just switch/case statements calling the actual handler procs.
Preparation for further steps.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These dispatcher functions are much more complex than they're usually are
(just switch/case statement). Bring them in line with the standard scheme
used in the Xserver, so further steps become easier.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Collect up the puzzle piezes of the reply payload into to a temporary struct,
so we can send it as one block. This allows for further simplifications by
subsequent commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Collect up the puzzle piezes of the reply payload into to a temporary struct,
so we can send it as one block. This allows for further simplifications by
subsequent commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The payload lengths is already known, so we can easily collect the data
in a stack buffer and only need one WriteToClient() operation.
This also clears the road for further simplification/unification of the
reply sending code, coming with follow-up commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify sending by collecting in a local scoped buffer, so only one
WriteToClient() call is needed. This also makes further simplifications
by upcoming patches easier.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The way it's currently done, indirectly via macros calling dedicated
functions, is unnecessarily complicated. Simply inline it, just like
(almost) all the other extensions are doing it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These dispatcher functions are much more complex than they're usually are
(just switch/case statement). Bring them in line with the standard scheme
used in the Xserver, so further steps become easier.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The current way of switching between Xinerama and single-screen handlers
is quite complicated and needs call vector tables that are changed on
the fly, which in turn makes dispatching more complicated.
Reworking this into a simple and straight code flow, where individual request
procs just look at a flag to decide whether to call the Xinerama or single
screen version.
This isn't just much easier to understand (and debug), but also removes the need
or the call vectors, thus allowing further simplification of the dispatcher.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
A little bit of code simplification by using static initialization
of struct right at the point of declaration. Also dropping a few now
unneccessary zero assignments.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The buffer should be small enough for easily fitting on stack, so let's
use that and never again worrying about forgotten free()'s :)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Formulate the buffer/field size computations a bit more verbose in
ProcXvQueryImageAttributes(), so they're easier to understand on
reading the code.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make sure it's really a 32bit integer, since we're hard-casting since
we're relying on the buffer being made of 32bit integers (and treating
it like CARD32's). If we encounter an arch, where int isn't 32bits,
the compiler should shout out loud now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify the dispatching by moving the branching between Xinerama
vs. single screen into the actual request handlers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The ProcVidModeGetAllModeLines() is a bit complicated, because reply structs
differ depending the active protocol version. In order to make it easier to
understand and allow further simplification of the request/reply marshalling
(see ticket #1701), splitting the two protocol versions into separate functions.
Also collecting the whole payload in a stack buffer (size is already known
anyways), in order to save arbirary number of individual WriteToClient() calls,
but send out the whole reply in one pass, which in turn allows further
simplifications in the sending path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for extra malloc()/free() round just for a tiny buffer that
easily fits on stack. Also allows further simplification of reply
sending by upcoming commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Collect up the puzzle piezes of the reply payload into to a temporary struct,
so we can send it as one block. This allows for further simplifications by
subsequent commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We can simply call SwapLongs() before writing out the CARD32 arrays.
No need using for complicated call back logic.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Semantically these are separate values in each branch any only used there,
so it's a bit more clean to move the declaration into the branches.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to go through global heap here, for such short-lived and
small buffers. And stack variables are automatically cleaned up
on leave.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The WriteSwappedDataToClient() already checks whether client is swapped
and directly calls WriteToClient() if it's not.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Coherently moving all reply struct decls and assignments into static
initialization right at declaration, just before it is getting byte-
swapped and sent out. Zero-assignments can be dropped here, since the
compiler automatically initializes all other fields to zero.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Some requests using different structs dependending on which protocol version
(v1 vs. v2) had been selected. That's is handled by coverting v1 structs into v2,
before proceeding with the actual handling.
The code flow of this is very complex and hard to understand. Cleaning this up
in several smaller steps, that are easier to digest.
This part moves the request payload structs (or pointers to them) into the
per-version branches. Within each branch following our usual scheme for
extension request handlers (eg. using the REQUEST*() macros and having a
pointer named `stuff` to the current request struct)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Some requests using different structs dependending on which protocol version
(v1 vs. v2) had been selected. That's is handled by coverting v1 structs into v2,
before proceeding with the actual handling.
The code flow of this is very complex and hard to understand. Cleaning this up
in several smaller steps, that are easier to digest.
This part is splitting the huge request handlers into upper and lower half,
where the upper is doing the version check and converting v1 requests into v2,
while the lower one is doing the actual request processing, operating on the
struct pointer passed in from the upper one, instead of the client struct's
request buffer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Some requests using different structs dependending on which protocol version
(v1 vs. v2) had been selected. That's is handled by coverting v1 structs into v2,
before proceeding with the actual handling.
The code flow of this is very complex and hard to understand. Cleaning this up
in several smaller steps, that are easier to digest.
This moving the request size check into the if-version-X branches, to make it
some bit easier to undertand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These dispatcher functions are much more complex than they're usually are
(just switch/case statement). Bring them in line with the standard scheme
used in the Xserver, so further steps become easier.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify the reply buffer handling and allocate it on stack. Also align it
with the scheme done in other extensions, which allows more simplification
via common macros in subsequent commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
When using static struct initialization, fields not explicitly
stated are automatically zero.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There's some piece ifdef'ed code that doesn't serve any practical purpose.
Instead add a little comment telling why that funny way of dispatching
(based on request size) is necessary.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In order to allow simplifying the reply send path, collect the reply
fragments into one buffer, instead of arbitrary number of WriteToClient()
calls. This also makes it much easier for potentially new purely packet-based
transports which (eg. binder) that would need their own stream parsing logic.
This xres function is an exceptionally hard case, since payload is constructed
step by step, and it's size only known when finished. The current way of the
fragment handling still has lots of room for improvement (eg. using very small
number of allocations), but leaving this for later exercise.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Collect the few bits in a local array, so one WriteToClient() call is
sufficient. That's also easing further simplifications in upcoming commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify allocaton by putting the small temporary int array onto stack.
This also allows further simplifications by upcoming commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Collect the few bits in a local array, so one WriteToClient() call is
sufficient. That's also easing further simplifications in upcoming commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify allocaton by putting the small temporary int array onto stack.
This also allows further simplifications by upcoming commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This macro doesn't do anything more than just making the function declarations
a few bytes smaller, but this makes the code harder to read (eg. when just
grepping through the code base).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Canonicalize all reply structures onto stack allocation and static
initialization, like already done in most other extension. So make
the code easier to understand and allow further simplifications by
subsequent commits. Also gaining a little bit efficiency by skipping
some heap allocations.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The dispatcher functions are much more complex than they're usually are
(just switch/case statement). Bring them in line with the standard scheme
used in the Xserver, so further steps become easier.
It's also much cleaner to use the defines from proto headers instead of
raw numbers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
