a) trade a little bit of code size for speed
(depending on exact caller, compiler might also optimize a lot)
b) reduce the need for exported, but non-public symbol
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external drivers, so no need to keep it in public SDK.
Since it's used by internal modules, still needs to be _X_EXPORT'ed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Still needs to be _X_EXPORT'ed for internal modules, but
not supposed to be visible to external drivers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Drop the -reset flag, so Xserver now either simply continues (w/o going
through internal reset) when last client disconnected or terminates
when -terminate is given.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of internally faking requests, factor out the actual logic
into separate function, which is getting everything it needs as
parameters, so no need to fiddle with request buffer anymore.
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>
The X11 protocol defines the sequenceNumber reply fields as `CARD16`, but the
Xserver is traditionally sloppy and using just `int`. Need to explicitly cast,
in order to silence compiler warnings.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We're trying to use size_t for sizes whereever possible, but WriteToClient()
is part of ABI, so we can't fix it's parameter types - need to explicitly
cast, in order to silence the compiler warnings.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use x_rpcbuf_t for payload assembly and X_SEND_REPLY_WITH_RPCBUF()
for sending it all out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is internal to DIX (used for assembling XQueryFont replies
and not used by any drivers (not even proprietary NVidia), and really
shouldn't ever called by them at all. It's been one the many victims of a
really unthoughtful mass export back 17 years ago.
That'S a necessary step for refactoring the RPC reply mechanics.
Since it's never used by any driver at all, we can easily to this change
within the current ABI level.
Fixes: d6cbd4511e
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Let X_SEND_REPLY_SIMPLE() macro return the X11 result code `Success`.
No change in semantics, just allowing a bit shorter typing, so one
can now directly write `return X_SEND_REPLY_SIMPLE(...)` in one line.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Needs to be bytes_to_int32() instead of pad_to_int32(), since we want
the amount of units instead of bytes here.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Check for rpcbuf error and return BadAlloc then, otherwise return Success.
This way, callers don't need to check their rpcbuf for error on their own
anymore, but can just do return X_SEND_REPLY_WITH_RPCBUF(...).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We need to call bytes_to_int32() instead of pad_to_int32(),
otherwise our computation is totally broken.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This macro is sending a reply header struct and rpcbuf payload
all in one shot. It also automatically computes the payload lengths
as well as also filling common fields like `type` and `sequenceNumber`
A typical call site looks like this:
> int ProcFooRequest(ClientPtr client) {
>
> [ ... ]
>
> X_SEND_REPLY_WITH_RPCBUF(client, rep, rpcbuf);
> return Success;
> }
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add macro X_REPLY_HEADER_UNITS() for computing how many extra
protocol units are needed for a reply header (for .length field)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use explicit cast to match WriteToClient()'s expectation and
return ssize_t, as coming from WriteToClient()
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The X protocol types from xorgproto all have corresponding sz_<typename>
defines with their actual network payload size (this can be checked via
SIZEOF() macro).
In theory, this should always be the same as sizeof(), but just to be sure,
adding a macro for a static assert on that.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Convenient helper function for creating atom and get it's ID.
If atom already exist, the existing ID is retrieved.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Helper function for retrieving _existing_ atom ID for given name.
If atom doesn't exist yet, it won't be created, but returning None instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Adding convenience function for writing out rpc buffer contents to
client and clear the buffer (free it's memory) afterwards.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Nvidia has a strange habit of messing with really internal stuff,
so need to add it to the executable's symbol table.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add a little helper that's looking up the ClientPtr to the client
of the owner of given XID. The lookup is solely done on the ID space,
the actual resource doesn't even need to exist.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Allow extensions to catch in right after a screen's root window has
been finally initialized
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>
Right now, extensions that need to be called after the CreateScreenResources
proc had been run, must wrap the screen proc vector directly (all of them
forming kind of daisy chain), and so - when called - temporarily restore the
previous one, call it, wrap again, and if the call was successful finally
doing it's own stuff. (same is done for many other procs)
While that approach is looking nice and elegant on the drawing board, it's
complicated, dangerous like a chainsaw and makes debugging hard, leading to
pretty blurred API borders.
Instead introducing a simple approach for letting extension hook into a
post-CreateScreenResources callback list safely, w/o having to care much
about side effects with the call chain. Extensions now can simply register
their business logic and get called back - w/o ever having to mess with the
ScreenRec's internal structures.
Note that these hooks are executed *AFTER* the original CreateScreenResources()
proc had been called SUCCESSFULLY (returned TRUE), so callees can rely on
the DDX/driver had already done it's job.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, extension specific pixmap destruction procedures are implemented
by wrapping the ScreenRec's DestroyPixmap() proc pointer: the extensions are
storing the original pointer in their private data and putting in their own one.
On each call, their proc restores the original one, calls it, and switches back
again. When multiple extensions doing so, they're forming a kind of daisy chain.
(the same is done for lots of other procs)
While that approach is looking nice and elegant on the drawing board, it's
complicated, dangerous like a chainsaw and makes debugging hard, leading to
pretty blurred API borders.
It's even getting worse: the proc also has to do ref counting, and only destroy
the pixmap if refconter reaching zero - that's all done in the individual screen
drivers. Therefore, all extensions must check for refcnt == 1, in order to know
when to really act.
This commit introduces a simple approach for letting extension hook into the
pixmap destruction safely, w/o having to care much about side effects with
the call chain. Extensions now can simply register their destructor proc
(and an opaque pointer) and get called back - w/o ever having to mess with
the ScreenRec's internal structures.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, extension specific actions on screen closing implemented by wrapping
the ScreenRec's PositionWindow() proc pointer: the extensions are storing the
original pointer in their private data and putting in their own one. On each
call, their proc restores the original one, calls it, and switches back again.
When multiple extensions doing so, they're forming a kind of daisy chain.
(the same is done for lots of other procs)
While that approach is looking nice and elegant on the drawing board, it's
complicated, dangerous like a chainsaw and makes debugging hard, leading to
pretty blurred API borders.
This commit introduces a simple approach for letting extension hook into the
screen closing path safely, w/o having to care much about side effects with
the call chain. Extensions now can simply register their hook proc (and an
opaque pointer) and get called back - w/o ever having to mess with the
ScreenRec's internal structures. These hooks are called before the original
vector (usually handled by DDX/screen driver directly) is called.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, extension specific actions on window positioning are implemented
by wrapping the ScreenRec's PositionWindow() proc pointer: the extensions are
storing the original pointer in their private data and putting in their own one.
On each call, their proc restores the original one, calls it, and switches back
again. When multiple extensions doing so, they're forming a kind of daisy chain.
(the same is done for lots of other procs)
While that approach is looking nice and elegant on the drawing board, it's
complicated, dangerous like a chainsaw and makes debugging hard, leading to
pretty blurred API borders.
This commit introduces a simple approach for letting extension hook into the
window positioning path safely, w/o having to care much about side effects
with the call chain. Extensions now can simply register their hook proc
(and an opaque pointer) and get called back - w/o ever having to mess with
the ScreenRec's internal structures. These hooks are called before the original
vector (usually handled by DDX/screen driver directly) is called.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, extension specific window destruction procedures are implemented
by wrapping the ScreenRec's DestroyWindow() proc pointer: the extensions are
storing the original pointer in their private data and putting in their own one.
On each call, their proc restores the original one, calls it, and switches back
again. When multiple extensions doing so, they're forming a kind of daisy chain.
(the same is done for lots of other procs)
While that approach is looking nice and elegant on the drawing board, it's
complicated, dangerous like a chainsaw and makes debugging hard, leading to
pretty blurred API borders.
This commit introduces a simple approach for letting extension hook into the
window destruction safely, w/o having to care much about side effects with
the call chain. Extensions now can simply register their destructor proc
(and an opaque pointer) and get called back - w/o ever having to mess with
the ScreenRec's internal structures.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, so no need to keep it exported.
It's also so simple (and rarely called) that easily can be inlined.
Also unexport HWEventQueueType and HWEventQueuePtr, since they're
not used by any drivers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
