Lots of logging functions, especially init and teardown aren't called
by any drivers/modules, so no need to keep them exported.
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>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
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>
When using static struct initialization, fields not explicitly
stated are automatically zero.
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>
WriteToClient() already checks for zero-length buffer and does nothing
in that case. So we can make the code a bit easier to read and also
allow further simplification of reply submission by upcoming commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make the code a bit easier to understand by declaring the variables
where they're first used instead of at the very top of the function.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Collect up the puzzle piezes of the reply payload into to a temporary buffer,
so we can send it as one block. This allows for further simplifications by
subsequent commits, as well as packet based transports and message based
compression.
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>
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>
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>
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>
* use static initialization where applicable
* drop unneeded setting of zero values
* use scoped variables
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of trying to calloc() zero-size blocks when there's no actual payload
to send, skip the whole part. This also helps reducing analyzer noise.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use static initialization where possible
* put the lists into one one block, so they can be written in one pass
* simplify size computations
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.
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>
* use their actual path instead of relying this to be in compiler's
include path list.
* no need to do it only conditionally, no #ifdef needed
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* use their actual path instead of relying this to be in compiler's
include path list.
* no need to do it only conditionally, no #ifdef needed
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
All relevant things are now in dix/colormap_priv.h, so no need
to include colormapst.h anymore.
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>
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.
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>
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>
a) an internal function that's not used by any drivers
b) conflicting with function/define of same name on win32
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There's no actual caller of this hook - removed almost a decade ago
(see commit 6cb34816af), but some remains
had been forgotten to clean up.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Enrico Weigelt, metux IT consult