There just had been for backwards compat with older driver sources
that hadn't been kept up to date yet. Not needed anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external drivers, so we can drop them and directly use
the corresponding fields.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not that the entries cannot change anymore, there's no need for having
a separate call table anymore - simply use switch/case.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that we don't have any SProc*'s anymore (everything now done by the
corresponding Proc*'s), there's no need for SProcRenderDispatch() entry
point and the SProcRenderVector[] call table anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for patching up the request buffer anymore - just pass in the correct
value directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This pointer just had been kept in at previous commit for keeping the
diff small and so easier to review. Now accessing the fields within
the local struct directly, dropping the extra pointer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for patching up the original request buffer anymore - just pass
in a modified copy.
Trying to keep this patch small for easier review. Some cleanups coming
with a follow-up.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of directly accessing the global screenInfo.screens[] array,
let everybody go through a little inline helper. This one also checks
for array bounds - if the screen doesn't exist, return NULL.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for patching up the request buffer anymore - just pass in the correct
value directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, so no need to keep it in public SDK.
Since it's not used by any drivers, effectively no ABI change, so
can be safely done within ABI-25.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
iterating over screen list via lambda-esque macros calls like this
DIX_FOR_EACH_SCREEN({
do_something
});
withing the body, the iterator variables `walkScreenIdx` and `walkScreen`
are defined and can be directly used (read-only). the code inside the body
is running in a separate scope.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Need to include renderproto.h
Closes: https://github.com/X11Libre/xserver/issues/700
Reported-By: Kevin Kofler <kevin@tigcc.ticalc.org>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Don't rely on this file just being included indirectly by somebody else
just by accident.
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>
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>
Several of the SProcRender*() functions aren't actually needed, because
they're doing exactly the same as their ProcRender*() counterparts.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
