Instead of dozens of little WriteToClient() calls, collect the sub-replies in
a buffer and send the whole reply out at once. This also allows more upcoming
simplifications in the send path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is a funny beast: it assembles and writes out an xkbGetGeometryReply,
called in two different cases, ProcXkbGetGeometry() as well as ProcXkbGetKbdByName().
In the latter case the whole reply is contained in another one. That's the reason
why it's payload size is computed separately - the caller must know that in order
to set up the container's reply size correctly.
As preparation for upcoming simplifications of the reply send path, splitting off
this function into pieces: XkbAssembleGeometry() just assembles the reply payload,
while it's callers now responsible for preparing the request header and writing
out both pieces.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is a funny beast: it assembles and writes out an xkbGetNamesReply,
called in two different cases, ProcXkbGetNames() as well as ProcXkbGetKbdByName().
In the latter case the whole reply is contained in another one. That's the reason
why it's payload size is computed separately - the caller must know that in order
to set up the container's reply size correctly.
As preparation for upcoming simplifications of the reply send path, splitting off
this function into pieces: XkbAssembleNames() just assembles the reply payload,
while it's callers now responsible for preparing the request header and writing
out both pieces.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is a funny beast: it assembles and writes out an xkbGetIndicatorMapReply,
called in two different cases, ProcXkbGetIndicatorMap() as well as ProcXkbGetKbdByName().
In the latter case the whole reply is contained in another one. That's the reason
why it's payload size is computed separately - the caller must know that in order
to set up the container's reply size correctly.
As preparation for upcoming simplifications of the reply send path, splitting off
this function into pieces: XkbAssembleIndicatorMap() just assembles the reply payload,
while it's callers now responsible for preparing the request header and writing
out both pieces.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is a funny beast: it assembles and writes out an xkbGetCompatMapReply,
called in two different cases, ProcXkbGetCompatMap() as well as ProcXkbGetKbdByName().
In the latter case the whole reply is contained in another one. That's the reason
why it's payload size is computed separately - the caller must know that in order
to set up the container's reply size correctly.
As preparation for upcoming simplifications of the reply send path, splitting off
this function into pieces: XkbAssembleCompatMap() just assembles the reply payload,
while it's callers now responsible for preparing the request header and writing
out both pieces.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is a funny beast: it assembles and writes out an xkbGetMapReply,
called in two different cases, ProcXkbGetMap() as well as ProcXkbGetKbdByName().
In the latter case the whole reply is contained in another one. That's the reason
why it's payload size is computed separately - the caller must know that in order
to set up the container's reply size correctly.
As preparation for upcoming simplifications of the reply send path, splitting off
this function into pieces: XkbAssembleMap() just assembles the reply payload,
while it's callers now responsible for preparing the request header and writing
out both pieces.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
For easier reading, move th sub-reply structs down to where they're used
first and use static initialization for the common fields.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Move down the declaration of the reply struct, right before swapping and sending
and use static initialization.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The function doesn't need to pass anything back via this pointer, it's
the last consumer of this struct. Make understanding the code a bit easier
and clear the road for further simplifications by passing the struct as
value instead of pointer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The function doesn't need to pass anything back via this pointer, it's
the last consumer of this struct. Make understanding the code a bit easier
and clear the road for further simplifications by passing the struct as
value instead of pointer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make the code flow a bit easier to understand and allow further simplification
by now just having to write out one additional payload as one block.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Consolidate the button action data into the payload struct added by previous
commit. So we can write it out (along with the name string) by just one call.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since the buffer is only used locally, it can easily be on stack.
Putting it into a struct, so following up buffers can be put in here,
and we'll still have only one write out call.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's hard to see which fields of the xkbGetDeviceInfoReply struct it's
reading or writing, and that complicates further simplifications of the
caller. So instead let the caller pass in the relevant fields and do the
modifications on the reply structs on its own.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
A bit more simplification by allocating the reply payload buffer on stack.
The extra length check (did we write as much as intended?) isn't necessary,
since the buffer size is computed by the very same data before this
function is called.
Hint: the size computation must be done before calling this one, because
the reply might be encapsulated in another one (xkbGetKbdByName).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's not passing back any data via that pointer and actually the last
consumer of it. Changing it to value instead of pointer clears the
road for further simplifications by subsequent patches.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's not passing back any data via that pointer and actually the last
consumer of it. Changing it to value instead of pointer clears the
road for further simplifications by subsequent patches.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's not passing back any data via that pointer and actually the last
consumer of it. Changing it to value instead of pointer clears the
road for further simplifications by subsequent patches.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We don't need the whole struct here, especially do we not wanna change it.
Therefore only pass in what's really needed, so it gets easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use static initializaton as much as possible and drop unnecessary
or duplicate zero assignments.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This has been nothing but an alias for two decades now (somewhere in R6.6),
so there doesn't seem to be any practical need for this indirection.
The macro still needs to remain, as long as (external) drivers still using it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
This has been nothing but an alias for two decades now (somewhere in R6.6),
so there doesn't seem to be any practical need for this indirection.
The macro still needs to remain, as long as (external) drivers still using it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
This has been nothing but an alias for two decades now (somewhere in R6.6),
so there doesn't seem to be any practical need for this indirection.
The macro still needs to remain, as long as (external) drivers still using it.
Fixes: ded6147bfb
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
If XkbComputeGetGeometryReplySize() returns an error, the XkbGeometryRec won't
be freed, since we're bailing out too early and not calling XkbSendGeometry().
Having XkbSendGeometry() responsible for freeing that struct is unnecessarily
complicated anyways, so move that to ProcXkbGetGeometry() and do it also when
XkbComputeGetGeometryReplySize() failed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1622>
The last use of struct '_SrvXkmInfo' was removed in
commit fbd7768946 ("XKB: Ditch XkbFileInfo").
Remove it.
The define MAX_TOC hasn't been used in this file since sometime
in the mid 90's; it's unused in version '1997/05/20 11:42:06'
but in '1.8 94/05/16 10:49:53' it's used in the definition
of _SrvXkmInfo.
Remove it.
Build tested.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1558>
These functions shouldn't be called by drivers or extensions, thus
shouldn't be exported. Also moving it to separate header, so the
already huge ones aren't cluttered with even more things.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1334>
