The DDX callbacks (where core/DIX calls into DDX) aren't supposed to be
called by drivers directly, so unexport them.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
systemd is linux specific and the actual implementation is under the
os-support layer of xfree86 ddx. Thus no need to keep it in global
include directory, putting it onto the linux specific os-support instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
DEV_MEM define isn't used by any drivers, and BSD seems to be the only
platform using /dev/pmem instead of /dev/mem - as well as the DEV_MEM
define from xf86_OSlib.h (Linux uses the symbol, but defines on its own)
Therefore, just define it where actually used and drop it from the global
xf86OSlib.h file.
Note that /dev/pmem refers to physical memory, not to be mixed up with
Linux's persistent memory subsys, which uses /dev/pmem[N] device nodes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Public server module API shouldn't be clobbered with private definitions,
thus move them out to private header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Doing so that struct OdevAttributes doesn't need to be exposed to
drivers anymore. It really doesn't seem to be a hot path, so not
inlining anymore shouldn't have any practical performance impact.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
public server module API headers shouldn't be clobbered with non-exported
definitions, so move them out to private header file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
public server module API headers shouldn't be clobbered with non-exported
definitions, so move them out to private header file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
public server module API headers shouldn't be clobbered with non-exported
definitions, so move them out to private header file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
public server module API headers shouldn't be clobbered with non-exported
definitions, so move them out to private header file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
public server module API headers shouldn't be clobbered with non-exported
definitions, so move them out to private header file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
public server module API headers shouldn't be clobbered with non-exported
definitions, so move them out to private header file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
public server module API headers shouldn't be clobbered with non-exported
definitions, so move them out to private header file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
public server module API headers shouldn't be clobbered with non-exported
definitions, so move them out to private header file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
public server module API headers shouldn't be clobbered with non-exported
definitions, so move them out to private header file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Resolve conflicts with OS headers definining IOBASE by renaming the
IOBASE enum value to XF86_TOKEN_IOBASE.
This way, don't need the special #undef hack anymore.
Resolve name conflict with Sun's <sys/kbd.h> by renaming STRING enum
value to XF86_TOKEN_STRING.
This way, don't need the special #undef hack anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These have been forgotten on some major cleanup back almost two decades ago.
(Daniel dropped a lot of dead code, which already had been removed earlier
but merged back accidentially).
Didn't look further back on where exactly they had become obsolete - being
unused for decades should be enough justification for dropping.
Fixes: 81913a1291
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>
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>
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>
Since we're now using xcb for upstream X11 connection, it's cleaner to
use it's type for the window IDs.
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