The symbol controls whether to include dix-config.h, and it's always set,
thus we don't need it (and dozens of ifdef's) anymore.
This commit only removes them from our own source files, where we can
guarantee that dix-config.h is present - leaving the (potentially exported)
headers untouched.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This doesn't seem to be used anymore for two decades now,
so there's probably no need to keep it any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's not good having the public server api headers clobbered with private
definitions, so cleaning them up.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Reduce cluttering public interface with non-exported stuff, moving those
things into a separate internal header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This file isn't included by any driver - not even indirectly, and hard
to imagine any driver ever needs it, so no need to keep it installed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several places using _X_ATTRIBUTE_PRINTF macro from X11/Xfuncproto.h
but missing to include it, so it depends on other headers whether it's
included by mere accident, which quickly causes trouble if include order
changes. Cleaning that up by adding explicit include statements.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These aren't used by any drivers/modules, so no need to keep them exported.
As already touching them, give them a proper name prefix for clarity.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This isn't needed by any external module, so no need to export it.
And those flags are better off in the corresponding extension,
instead of the OS layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This isn't needed by any external module, so no need to export it.
And those flags are better off in the corresponding extension,
instead of the OS layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This isn't needed by any external module, so no need to export it.
And those flags are better off in the corresponding extension,
instead of the OS layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This isn't needed by any external module, so no need to export it.
And those flags are better off in the corresponding extension,
instead of the OS layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since most of the extension init logic (and on/off switches for them)
is driven from miext, this seems the appropriate place for the header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several sources including it without need. For consistency, those who still
need someting from there should include exitinit_priv.h (which also pulls
in extinit.h)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These code pieces have been commented out since their introduction back
almost two decades ago, so probably no need for them anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have one function doing nothing more than calling another one
with the same prototype.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of highjacking core request handlers, use the recently introduced
DDX/driver API.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This file became pretty no-op, just including dix-config.h.
So we can remove it now and include dix-config.h directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of strange #undef hacks in various places, just go the straight
route and set the corresponding no*Extension flags on server startup.
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 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>
Now that we completely ported from Xlib to XCB, we can finally stop
importing Xlib :)
FIN.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that no Xlib operations (besides opening and closing connection)
aren't used anymore, we can move over the last pieces and use XCB
instead of Xlib for connecting the upstream Xserver.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that no X11 calls are being done via Xlib anymore, we're free to
also move over event receiving, leaving Xlib pretty much unused.
Also need to add a simple event queue mechanism, because we've go a
screen operation (see xnestBitBlitHelper) that needs to collect up
certain events for it's return value.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
xnestWindowExposures() is a micro-optimization for the specific case that
a newly created window receives exposure events (from our upstream server)
inside the region we're already exposing on our own (miWindowExposures()):
it peeks the Xlib event queue for all expose events, checks whether their
areas are inside our exposure region and requeue's those that aren't.
Unfortunately, this depends on Xlib's internal queue mechamism, thus standing
in the way of moving to XCB (which doesn't have that).
Removing this doens't seem to make any practical difference, even with
demanding applications like GIMP. The only cost is potentially having some
initial window content painted twice, *if* the application really draws
something complicated right after creating the window.
*If* there'll really be a demand for such an optimization some day, it can
be reimplemented without any message queue: just redirecting all expose events
into recording them in a region, which is flushed out later. But for now,
there really doesn't seem to be any practical need for that.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Enrico Weigelt, metux IT consult