Move the callbacks directly into DIX, since it's actually core infrastructure.
Also simplifying the whole machinery, by just using a simpel CallbackListPtr.
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>
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>
rename them to indicate that they're not the global payload buffer,
but temporary childs for sub-replies.
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 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>
Instead of memset()ing all the structs and then assigning (overwriting)
invidual fields one by one, use static init and let the compiler find out
on its own how to do it the best way.
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>
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>
Add extra check for comparing the actually written sub-payload sizes
with their previously computed ones. This is meant for troubeshooting
while still stabelizing the previous, not entirely trivial commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add and use macro X_REPLY_HEADER_UNITS() for computing how many
extra protocol units are needed for a reply header (for .length field)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use x_rpbuf_t instead of raw buffer for assembling and byte-swapping
indicator map payload.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since no consumer of this rpcbuf is writing directly to the underlying
buffer space anymore, there's no need to explicitly make room.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
