No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Move functions/macros dealing with request parsing or reply assembly/write
out of the big dix_priv.h into their own headers. This new header will also
get more of those function/macros soon (yet still in the pipeline).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This hook was never used, so no need to keep around something that's
really not used anywhere.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Follow-up on renaming dixGetFirstScreenPtr() to dixGetMasterScreen():
also rename the target variables for correct technical terminology.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In Xinerama/Panoramix configuration there's one screen that's having special
meaning - it's used for simulating as the frontend for all client operations:
the clients (should) only talk to that screen, while panoramix subsystem is
proxying those operations to all the other screens (with certain changed
applied, eg. coordinate transformations).
Historically, this screen happens to be the first one in the system (some of
it's proc's are hooked up in order to achieve desired behaviour). That's why it
used to be accessed via screenInfo.screens[0] - that already had been encapsulated
into a tiny helper `dixGetFirstScreen()`.
a) the correct terminus technicus for a situation where one device (or SW entity)
entirely controlling others is a master-slave-relationship: the controlling
device/entity is `master`, the controlled ones are `slave` (to that specific
master).
b) the term "first screen" is inacurate and misleading here: what the caller's are
actually interest in isn't the first entry in the screen array, but the screen
that's controlling the others. With upcoming refactoring of the Xinerama/Panoramix
subsystem, this might well be a different array index than 0.
c) the term `default` also wouldn't match: `default` implies there's a real practical
choice, and such value applies when no explicit choice has been made. But in this
case, it practically doesn't make sense (except perhaps for debugging purpose)
for a client to use any different screen.
Therefore fixing the function name to the correct technical terminology.
(for sake of patch readability, renaming corresponding variables is left to
subsequent patches).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of having huge number of micro-headers, consolidate all the
request handler prototypes in one file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of everybody directly accessing the (internal) screenInfo struct,
let those consumers only interested in first screen use a little helper.
Also caching the value if it's needed several times.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In preparation of upcoming screen iterator macros, compactify the
loop body a little bit. This function is so cold that it's not
really worth caching the screen's root window pointer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The macro will automatically return BadAlloc if the buffer is broken,
otherwise Success. Thus, we don't need extra prior rpcbuf check.
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>
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>
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>
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>
When iterating screen lists, consistently use the same variable name
`walkScreen` for holding current screen pointer everywhere.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The client index (in the client table) can never be negative, thus
make it an unsigned short.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use x_rpcbuf_t for reply payload assembly and byte-swap, instead of
writing in little pieces via complicated callbacks.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Skip allocation of temporay buffer for the atom IDs, instead walk through
the property list and write the IDs directly into the rpcbuf.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
