Several SProc's have become no-ops, just calling the actual Proc's,
so we can get rid of them entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several SProc's have become no-ops, just calling the actual Proc's,
so we can get rid of them entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several SProc's have become no-ops, just calling the actual Proc's,
so we can get rid of them entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several SProc's have become no-ops, just calling the actual Proc's,
so we can get rid of them entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several SProc's have become no-ops, just calling the actual Proc's,
so we can get rid of them entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several SProc's have become no-ops, just calling the actual Proc's,
so we can get rid of them entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several SProc's have become no-ops, just calling the actual Proc's,
so we can get rid of them entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several SProc's have become no-ops, just calling the actual Proc's,
so we can get rid of them entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Most of the complexity here isn't needed at all. It can be really trivial,
since we just have one operation anyways.
It's also much cleaner to use the defines from proto headers instead of
raw numbers.
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>
Simplify allocaton by putting the small temporary int array onto stack.
This also allows further simplifications by upcoming commits.
The upper bound is determined by the number of resource types registered
in the server - this can only be increased by writing new extensions.
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>
Simplify allocaton by putting the small temporary int array onto stack.
This also allows further simplifications by upcoming commits.
Note: there's an upper bound by compile time defines (theoretically, can
be increased by special cmdline args, that virtually nobody ever using).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify the dispatching by moving the branching between Xinerama
vs. single screen into the actual request handlers.
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>
This reverts commit 58a2fb8b6f.
Needed by xf86-video-intel driver. Didn't get noticed, because we don't
have this driver in our CI yet.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Direct calls to ScreenRec->DestroyPixmap() blocks cleaning up the wrapping
jungle, so use the proper dix function instead.
See: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1754
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Direct calls to ScreenRec->DestroyPixmap() blocks cleaning up the wrapping
jungle, so use the proper dix function instead.
See: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1754
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, we're assuming that even when deep nesting involved, the proc
vector is always set to a valid function. One the one hand it requires
extra dummy procs in some cases, OTOH it's making upcoming refactoring
of the code flow unnecessarily complex.
The big plot (of subsequent commits) is splitting out the extension's
(and possibly subsystem's) special logic out of the wrapping chain and
let them be executed independently from the DDX/drivers - when applicable
even only when the pixmap is really destroyed (not just unref'ed).
(At some later point, it might even become be actually a valid situation
that DestroyPixmap vector really being NULL.)
See: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1754
See: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1755
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Split reply header and payload buffers. Making it more coherent with all the
other request handlers, and allows a lot of further simplification by using
generic macros (coming in subsequent commits).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1600>
There's some piece ifdef'ed code that doesn't serve any practical purpose.
Instead add a little comment telling why that funny way of dispatching
(based on request size) is necessary.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1600>
Enrico Weigelt, metux IT consult