Little helper function for checking whether a resource XID
belongs to the server itself.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Retrieves the ClientPtr for the owner of given resource.
This way reducing the sites directly accessing clients[] array.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make it type-safe and a bit more obvious what it really does,
also adding some inline documentation. Since it's just some
bit shifting magic, it's qualified for inlining.
The CLIENT_ID() macro isn't used by any external modules, so the
new function doesn't need to be in a public header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Helper function for retrieving the owning client of an OtherClients.
It's an actual function, so callers don't need access to internal
knowledge (definition of struct _OtherClients, clients[] array, ...)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Hide internals (drop the need to include windowstr.h), make it typesafe
as well as the naming easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
Wrapping ScreenRec's function pointers is problematic for many reasons, so
use the new pixmap destroy notify hook instead.
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 pixmap destroy notify hook instead.
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>
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>
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>
Wrapping ScreenRec's function pointers is problematic for many reasons, so
use the new window destructor hook instead.
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>
* 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>
