No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for using a complex callback machinery, if we just move the
little pieces of byte-swapping directly into the request handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers/modules, so no need to keep it exported.
Also adding a bit of documentation.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The supported platforms already have asprintf() and vasprintf(),
so there's no need for having our own implementation anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We can write down the function name directly. Nobody else than a few
define's in here using that macro.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make it type-safe and a bit more obvious what it really does,
also adding some inline documentation. Since it's just some
bit shifting magic, it's qualified for inlining.
The CLIENT_ID() macro isn't used by any external modules, so the
new function doesn't need to be in a public header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Helper function for retrieving the owning client of an OtherClients.
It's an actual function, so callers don't need access to internal
knowledge (definition of struct _OtherClients, clients[] array, ...)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Hide internals (drop the need to include windowstr.h), make it typesafe
as well as the naming easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The old PCCONS driver only seems to be used on minimal install disks and
cannot coexist with newer ones (at least that's the feedback I've gotten
from BSD community), so there's probably no practical use case for
supporting it in Xorg anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Both xlib as well as the Xserver use the same identifier "GC" for
different types. While on xlib it's just the numerical ID of a GC,
the xserver defines a struct for it by the same name. This is this
ugly and needs ridiculous hacks for Xserver code that needs xlib.
Easy to solve by just renaming the GC typedef to GCRec (consistent
with how we're naming other structs) and replacing GC* by GCPtr.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Usually no*Extension fields shouldn't be needed by drivers, but there
are a few exceptions: some drivers need to know whether composite or
Xinerama are active.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Enrico Weigelt, metux IT consult