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.
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.
Add a server flag (AllowEmptyInput), which will inhibit adding the
standard keyboard and mouse drivers, if there are no input devices in the
config file.
Always add a mouse driver instance configured to send core events, unless
a core pointer already exists using either the mouse or void drivers. This
handles the laptop case where the config file only specifies, say,
synaptics, which causes the touchpad to work but not the pointing stick.
We don't double-instantiate the mouse driver to avoid the mouse moving twice
as fast, and we skip this logic when the user asked for a void core pointer
since that probably means they want to run with no pointer at all.
Remove most of the rest of the old keyboard driver.
Move to the new Get{Keyboard,Pointer}Events API, which is mostly
complete at this stage: just missing the proximity events.
Get rid of almost all uses of these definitions. They're still defined for
delinquent out-of-tree drivers, and also for the Mesa build. As well as
for miinitext.c. But largely gone.
- add hw/xfree86/utils/cvt/, cvt.c, cvt.man.pre and Makefile.am.
- Adjust configure.ac and hw/xfree86/utils/Makefile.am for cvt.
- Add MonPtr->reducedblanking and Option "ReducedBlanking" to the Monitor
section.
- Check for reduced blanking in xf86CheckModeForMonitor and disallow modes
with less than 25% blanking otherwise.
- Fix some warnings in hw/xfree86/common/xf86Config.c.
Add XSERV_t, TRANS_SERVER, TRANS_REOPEN to quash warnings.
Add #include <dix-config.h> or <xorg-config.h>, as appropriate, to all
source files in the xserver/xorg tree, predicated on defines of
HAVE_{DIX,XORG}_CONFIG_H. Change all Xfont includes to
<X11/fonts/foo.h>.
number of preallocated slots. We should really make this dynamic - but
I don't think this ever caused a problem so it's more or less academic.
A. Avoid that *SyncStart starts before *BlankStart. If *BlankStart >
*SyncStart it is made = *SyncStart and its width is made maximal but such
that the blank does not exceed *Total. Since the Sync width has the
same restrictions as the Blank width monitors should still be able to
clamp after the sync pulse. B. Over time mode validation has become
inconsistent when people started to add additional features to the mode
validation. One such feature is that the mode->Crtc* values have been
(ab)used to allow the driver ValidMode() function to pass driver
normalized timing values back to the validation function. The
introduction of these features made the code less readable and created
numerous possibly unintended side effects in the validation semantics.
I've attempted to consolidate these changes making the code more
consistent and eliminating a number of side effects. This should not
cause problems for the majority of drivers, still it should receive
testing - especially with ATi Mach64 and Radeon code. (Bugzilla #3325).