Was only used to provide a list of input devices that XF86-Misc could use,
now that XF86-Misc is gone, was parsed and logged, then completely ignored.
(Depends on previous patch that introduces OBSOLETE_TOKEN in parser to
make obsolete keywords like InputDevices & RgbPath be non-fatal errors.)
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Acked-by: Adam Jackson <ajax@redhat.com>
This was all a glorified no-op. We rely on pciaccess to create device
maps anyway, so we should have no reason to care about what the host
address is.
Acked-by: Ian Romanick <ian.d.romanick at intel.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
By making the "Unable to open config file" header a warning, it was
not appearing with the filename when a config file was specified and
not found. Now we make it an error message again, but only issue
the error if a filename was specified - if none was specified, then
we don't even issue a warning, just the "Using autoconfig" info message.
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Instead of always keeping two copies of the keymap, only generate the
core keymap from the XKB keymap when we really need to, and use the XKB
keymap as the canonical keymap.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We already have state fully stored within XKB, so instead of duplicating it,
just generate the values to send to clients when required.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
XkbInitKeyboardDeviceStruct is now the only valid keyboard
initialisation: all the details are hidden behind here. This now makes
it impossible to supply a core keymap at startup.
If dev->key is valid, dev->key->xkbInfo->desc is also valid.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No more #ifdef XKB, because you can't disable the build, and no more
noXkbExtension either.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we can't enable a device, bail out of NewInputDeviceRequest rather than
blithely continuing. Also, be more verbose when initialization failed. Also,
be more verbose when initialization failed. Also, be more verbose when
initialization failed. Also, be more verbose when initialization failed.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There are several other direct calls to free, check
% egrep '\<free\(' `find . -name \*.c`
but they are free'ing memory from explicit malloc calls.
This one was not intended, and corrected, so that it would
both, follow the conventions everywhere (and work on some
libc that doesn't like free(0)), and make it easier to use
malloc wrappers.
The builtin-fonts configure option was removed, as it at best should
have been a runtime option. Instead, now it always register all "font
path element" backends, and adds built-ins fonts at the end of the
default font path.
This should be a more reasonable solution, to "correct" the most
common Xorg FAQ (could not open default font 'fixed'), and also don't
break by default applications that use only the standard/historical
X Font rendering.
Add a ClipNotify helper that lets the driver know about changes in the
clipping of an Xv backing drawable.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Devices are only activated once - right after they've been added to the
server. If a device failes activation, it's dead. There's no reason to
continue. Return the error code from ActivateDevice() without setting up
sprite information or even sending a event to the client.
Then - in the DDX - just remove the device again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
- The Gamma values from the monitor section are now used during initial config.
- The old colormap system is disabled when gamma set hook is available.
- Gamma values are now persistent for the lifetime of the xserver.
- This requires no driver changes and should be driver ABI compatible.
A grep on xorg/* revealed there's no consumer of this define.
Quote Alan Coopersmith:
"The consumer was in past versions of the headers now located
in proto/x11proto - for instance, in X11R6.0's xc/include/Xproto.h,
all the event definitions were only available if NEED_EVENTS were
defined, and all the reply definitions required NEED_REPLIES.
Looks like Xproto.h dropped them by X11R6.3, which didn't have
the #ifdef's anymore, so these are truly ancient now."
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
The awk script was incorrectly referencing the struct name, and
not the struct variable.
Also added some comments to sdksyms.sh, for the reason it generates
the "symbol table" and add a message to the generated file, telling
is was automatically generated.
The kbd driver may send events during device initialisation, and these events
need the EQ set up already.
X.Org Bug 18890 <http://bugs.freedesktop.org/show_bug.cgi?id=18890>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
As suggested by Julien Cristau
This is an follow-up to
commit 9c5dd7337f
Author: Peter Hutterer <peter.hutterer@redhat.com>
Date: Wed Dec 3 14:24:25 2008 +1000
Let the DDX decide on the XkbRulesDefaults.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Acked-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
drv and idev are only set for SDs, but are only dereferenced for SDs too, so
initializing them to NULL is safe.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
It is declared as
<hash>ifdef HAVE_ACPI
Bool xf86acpiDisableFlag = FALSE;
<hash>endif
in hw/xfree86/common/xf86Globals.c
but not protected by the ifdef in the sdk header xf86Priv.h, what
caused a build failure in the tinderbox, due to the address of the
symbol being taken (to ensure it is available) in sdksyms.c.
All .a libraries were converted to .la, and instead of linking the
Xorg binary with a mix of .a and .la, and adding some libraries more
then once in the command line, etc, now it generates a single libxorg.la
from all the required convenience libraries, and links with a dummy
xorg.c (that should usually be the file with the main function...).
This removes the requirement of some things like libosandcommon and
libinit, that existed to circumvent problems when linking multiple
.a and .la in the final Xorg binary.
The "symbol table" is now generated dynamically, by a shell script,
with an embedded gawk parser that parses cpp output. The new file
sdksyms.sh is generated by hand by analyzing all Makefile.am's and
making it create a sdksyms.c file, that includes all sdk headers that
will add symbols for the Xorg binary. Module headers aren't read, and
a in 2 files it was required to add a "<hash>ifndef XorgLoader" around
declarations shared between the Xorg binary and libextmod. A few
other changes were added to other sdk headers, like preventing
multiple inclusion, or including other headers to satisfy dependencies.
This should be a lot more portable, and better (hopefully properly)
using libtool to generate convenience libraries.
Those tables were once used to decide what symbols are visible to
modules, but they were outdated. The only real usage was that, since
it was taking the address of symbols, linkage should fail if the
symbols were not available.
Now the proper way to make symbols available to modules should
be to use the _X_EXPORT macro, or not compile with hidden symbols,
so that all symbols would be available.
All symbols in the tables were revised to ensure they are exported,
and only symbols that were not exported are ClientSleepUntil() and
DuplicateModule(), that were not in the sdk for quite some time
already, and should not have any users outside of the X Server
(and/or builtin modules).
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).
Rather than assuming rules in the CoreKeyboardProc, init the default rules in
InitCoreDevices, then re-use them later.
In the xfree86 DDX, set the rules to "base" or "evdev", depending on whether
we'll load kbd or evdev.
If we create a new MD, use pc105,us as default and re-use the rules file used
previously.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
