Now that libXextmodule.la is both empty and unused, we can just build
the one libXext.la for everyone, rather than having Xorg be special and
unique.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
extmod was originally a big pointless module. Now it's an empty,
pointless module. This commit makes it unexist.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Instead of letting it languish in extmod just because we want to
configure bits of it from xf86, move XSELinux to the builtin part of
Xext, and do its configuration from xf86ExtensionInit.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Always build these extensions into the core server, rather than letting
them languish in extmod.
Signed-off-by: Tomas Carnecky <tom@dbservice.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Always build XRes support into the core server, rather than letting it
languish in extmod.
Signed-off-by: Tomas Carnecky <tom@dbservice.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Always build DPMS support into the core server, rather than letting it
languish in extmod.
Signed-off-by: Tomas Carnecky <tom@dbservice.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
If we've built MIT-SCREEN-SAVER support, then just build it into the
main binary, rather than leaving it in extmod.
Signed-off-by: Tomas Carnecky <tom@dbservice.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The generic hashtable implementation adds a key-value container, that
keeps the key and value inside the hashtable structure and manages
their memory by itself. This data structure is best suited for
fixed-length keys and values.
One creates a new hash table with ht_create and disposes it with
ht_destroy. ht_create accepts the key and value sizes (in bytes) in
addition to the hashing and comparison functions to use. When adding
keys with ht_add, they will be copied into the hash and a pointer to
the value will be returned: data may be put into this structure (or if
the hash table is to be used as a set, one can just not put anything
in).
The hash table comes also with one generic hashing function plus a
comparison function to facilitate ease of use. It also has a custom
hashing and comparison functions for hashing resource IDs with
HashXID.
Reviewed-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Signed-off-by: Erkki Seppälä <erkki.seppala@vincit.fi>
Nobody can have been using this, it's never called from extension init.
XI2 device properties should now be a functional replacement.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Initial server side implementation of fence sync
objects. Allows creation, management, and state
queries of binary state objects. Currently they
are not very useful as there is no way to wait for
them efficiently.
The basic trigger operation added here triggers
relative to a given X screen's rendering operations.
To perform this operation, fence sync objects must
be tied to a screen. As Aaron Plattner pointed out,
screens are identified but a drawable in X protocol,
so a drawable argument is included in
XSyncCreateFence(). The screen also could have been
specified as part of the trigger operation. However,
it is also desireable to associate a screen with
fence sync objects at creation time so that the
associated screen's driver can allocate any HW-
specific resources needed by the fence object up
front.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
The rationale behind is because no sane application will use this when we have
modern APIs such DRI2. Besides, as a fact, xfree86 server has already
deprecated this extension in 1998:
http://www.xfree86.org/3.3.6/isc7.html
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Xext/xf86bigfont.c contains three non-static functions which are called
elsewhere in the server. This creates a new header containing these
declarations in order to fix several warnings:
xf86bigfont.c:285: warning: no previous prototype for `XF86BigfontFreeFontShm'
dixfonts.c:502: warning: implicit declaration of function `XF86BigfontFreeFontS$
dixfonts.c:502: warning: nested extern declaration of `XF86BigfontFreeFontShm'
log.c:436: warning: implicit declaration of function `XF86BigfontCleanup'
log.c:436: warning: nested extern declaration of `XF86BigfontCleanup'
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Although the DDX should be linked to the necessary libraries, we may
also need to pull them in directly to the module to ensure the symbols
are resolved at runtime. Should fix this bug with XSELINUX:
/usr/bin/X: symbol lookup error:
/usr/lib64/xorg/modules/extensions/libextmod.so: undefined symbol:
is_selinux_enabled
-v2: use _LIBADD instead of _LIBS; remove SELINUX_LIBS from
XSERVER_SYS_LIBS as it should only be needed in extmod.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Save in a few special cases, _X_EXPORT should not be used in C source
files. Instead, it should be used in headers, and the proper C source
include that header. Some special cases are symbols that need to be
shared between modules, but not expected to be used by external drivers,
and symbols that are accessible via LoaderSymbol/dlopen.
This patch also adds conditionally some new sdk header files, depending
on extensions enabled. These files were added to match pattern for
other extensions/modules, that is, have the headers "deciding" symbol
visibility in the sdk. These headers are:
o Xext/panoramiXsrv.h, Xext/panoramiX.h
o fbpict.h (unconditionally)
o vidmodeproc.h
o mioverlay.h (unconditionally, used only by xaa)
o xfixes.h (unconditionally, symbols required by dri2)
LoaderSymbol and similar functions now don't have different prototypes,
in loaderProcs.h and xf86Module.h, so that both headers can be included,
without the need of defining IN_LOADER.
xf86NewInputDevice() device prototype readded to xf86Xinput.h, but
not exported (and with a comment about it).
Conflicts:
Xext/xprint.c (removed in master)
config/hal.c
dix/main.c
hw/kdrive/ati/ati_cursor.c (removed in master)
hw/kdrive/i810/i810_cursor.c (removed in master)
hw/xprint/ddxInit.c (removed in master)
xkb/ddxLoad.c
This extension provided bug-compatibility with pre-X11R6, but has been
stubbed out in our server since 2006 to return BadRequest when you actually
asked for it.
Allow the location of the SERVERCONFIGdir variable to be defined at
compile-time. This allows us to specify where the security policy will be
located (Debian uses this to put it in /etc). The default is to the
previous location.
This adds (unconditional) support for the GE extension. Anything from now on
that sends events in MPX will have to use the GE extension. No GE, no MPX
events. GE is not actually used yet from anywhere with this commit.
You will need to update x11proto, xextproto, libX11, libXext and xcb to the
matching xge branches. Things will _NOT_ work without the updated protocol
headers and libraries.
