Make sure the font path is always 'built-ins' when we use built-in fonts,
rather than having it as a fixed path for a while, then clobbering it
halfway through startup.
If your loader is as bad as elfloader, then it makes sense for the
server to have some stubs for you to assign to / break on. However it
is no longer 1996.
I made a mistake in some new code using MakeAtom, passing the size of the
string instead of the length of the string. Figuring there might be other
such mistakes, I reviewed the server code and found four bugs of the same
form.
When the root window changed size, xf86XVFillKeyHelper would not revalidate
the GC, leaving the clip at the old size causing lossage (and possibly
memory corruption if the screen and frame buffer shrank).
Fixed by just using a scratch GC; saving memory, eliminating bugs and
shrinking the code.
When the modules section is parsed, if a module is set to be loaded by
default, this will be logged. If it is redundantly specified in xorg.conf,
this will also be noted. None of this logging will happen if the xorg.conf
lacks a modules section.
This provides a new option, UseDefaultFontPath. This option is enabled by
default, and causes the X server to always append the default font path
(defined at compile time) to the font path for the server. This will allow
people to specify additional font paths if they want without breaking
their font path, thus hopefully avoiding ye olde "fixed front" problem.
Because this option is a ServerFlag option, the ServerFlags need to be
processed before the files section of the config file, so swap the order
that they are processed.
Provide default modules that may be overrided easily. Previously the
server would load a set of default modules, but only if none were
specified in the xorg.conf, or if you didn't have a xorg.conf at all. This
patch provides a default set and you can add only the "Load" instructions
to xorg.conf that you want without losing the defaults. Similarly, if you
don't want to load a module that's loaded by default, you can add "Disable
modulename" to your xorg.conf (see man xorg.conf in this release for
details). This allows for a minimal "Modules" section, where the user only
need specify what they want to be different. See bug #10541 for more.
The list of default modules is taken from the set loaded by default when
there was a xorg.conf containing no "Modules" section.
A potential problem for some users is that some users disable a module,
most notably DRI, by commenting out the "Load" line in their xorg.conf.
This needs to be changed to an uncommented "Disable" line, as DRI is
loaded by default.
By the time CloseScreen gets called, we can't call ProcessInputEvents, as
the event queue will get unhappy. So just unregister our hooks instantly,
and hope that they don't get called.
When we see an evdev or vmmouse section, assume that it's a mouse, and
don't add a default mouse device. This will break users who have an
evdev keyboard section but no mouse, and want the mouse to get added
by default.
The former <X11/extensions/XKBsrv.h> has been pulled into the server now as
include/xkbsrv.h, and the world updated to look for it in the new place,
since it made no sense to define server API in an extension header. Any
further work along this line will need to do similar things with XKBgeom.h
and friends.
Code added in hw/xfree86/modes came from the server-1.3-branch.
Portions of this code had previously been integrated into xf86Mode.c
and edid_modes.c.
To preserve hw/xfree86/modes as much as possible, the duplicate code from
the other files has been disabled; a more careful review would figure out
where that code actually belonged.
Our modes typically come from EDID or default modes, and when the monitor
asks for a specific mode, deciding to tweak it usually results in incorrect
display. And if the user is specifying a mode by hand, tweaking it then is
still pretty rude.
Reviewed by: ajax
There's no need to store the slot information for a PCI device as its
ID. Instead, skip the middle man and just store a pointer to the
pci_device structure.
Rather than allocate a 9 byte buffer on each invocation, use a static
16 byte buffer. Use snprintf for safety. This commit should probably
be cherry-picked to the trunk.
Eliminate xf86GetPciDomain. The domain from libpciaccess is the
domain. Period. This means that 0 is a valid domain. Make sure that
INCLUDE_XF86_NO_DOMAIN is *not* set. Always run in "domain mode,"
even if the only domain possible is 0.
This also removes static from some other functions that had been copied out
to at least the intel driver, but perhaps others that were doing mode list
handling.
As discussed on the mailing list, people would rather have an X command-line
option to print the module path so installers can know where to put modules,
rather than the installers using `pkg-config --variable=moduledir xorg-server`,
since some distros choose not to install xorg-server.pc.
xf86 drivers need to create RandR object in the PreInit stage,
before the ScreenRec is allocated. Changing the RandR DIX code
to permit this required the addition of functions that later associate the
objects with the related screen.
An additional change is that modes are now global, and no longer associated
with a specific screen. This change actually makes mode management cleaner
as there is no more per-screen list of modes to deal with.
This changes the RandR 1.2 ABI/API for drivers.
