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>
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>
> In file included from ../Xext/xvdisp.c:33:
> ../Xext/xvdisp.c: In function ‘ProcXvQueryImageAttributes’:
> ../Xext/xvdisp.c:768:19: warning: typedef ‘int_size_wrong_’ locally defined but not used [-Wunused-local-typedefs]
> 768 | __size_assert(int, sizeof(INT32));
> | ^~~
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>
Move the walking loops on Xinerama screens into lambda-esque macros:
the callers look quite like we've been using lambda functions and
closures, but actually are just fancy macro trickery.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
When iterating screen lists, consistently use the same variable name
`walkScreenIdx` for holding current screen index everywhere.
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>
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>
in preparation of upcoming new iterator macros, phase out
FOR_NSCREENS_FORWARD_SKIP, so we don't need an additional macro
for just the case where first screen is skipped.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use the payload size from the rpcbuf, but also compare that with our
computation as sanity check and log error on mismatch.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead doing an exrtra loop for our own calculation of the
payload size, just the wpos from rpcbuf.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In preparation for subsequent refactoring, assembling the reply header
at once, instead of doing it piece by pice.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The payload length is already known after writing everything to the
buffer, so no need for extra size computation anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Preparation for subsequent changes: instead of returning early when no
payload to send, move that into a conditional block.
(the WriteRpcbufToClient() call on potentially empty buffer is intentional)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
As a prepration for upcoming changes, move assembly of the the reply
header further downwards where all values are already known, so we'll
have to touch it only once. Also eliminate the separate write path for
the case where Xv is disabled.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
For easier understanding the code, declare the variables right where
they're assigned first.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
some bit better naming for config symbols.
Yet leaving the old one defined, until all drivers have kept up.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of complex macro machinery, just move the conditional swapping
directly into ProcXvListImageFormats ().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of complex macro machinery, just move the conditional swapping
directly into ProcXvQueryImageAttributes().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of complex macro machinery, just move the conditional swapping
directly into ProcXvQueryPortAttributes().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of complex macro machinery, just move the conditional swapping
directly into ProcXvQueryBestSize().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of complex macro machinery, just move the conditional swapping
directly into ProcXvGetPortAttribute().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of complex macro machinery, just move the conditional swapping
directly into ProcXvGrabPort().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of complex macro machinery, just move the conditional swapping
directly into ProcXvListImageFormats().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of complex macro machinery, just move the conditional swapping
directly into ProcXvQueryPortAttributes().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of complex macro machinery, just move the conditional swapping
directly into ProcXvQueryAdaptors().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of complex macro machinery, just move the conditional swapping
directly into ProcXvQueryEncodings().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of complex macro machinery, just move the conditional swapping
directly into ProcXvQueryAdaptors().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of complex macro machinery, just move the conditional swapping
directly into ProcXvQueryEncodings().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
