ChangeLog
include xorg-config.h for modular build
Adjust XF86CONFIG defines for modular build
Fixes for modular build:
- include modular server config headers
- change default XCONFIGFILE to xorg.conf
- define XKB_RULES_DIR if not defined by Imake
than the max, it was bumped, and then if you were above the threshhold
you got moved in. Instead, do the above-threshhold check separate from
score starting out less than max. While this will likely make thrashing
cases worse, I hope it will fix some issues with long term performance
(think of an xcompmgr with a backbuffer it's doing only accelerated
operations to. If some new pixmap comes in and bumps it out, even once,
it will never get a chance to re-migrate because its score will be
maxed). Change migration-out to be the same way for symmetry, though it
shouldn't ever affect anything.
- Fix a lot of debugging output, both in terms of printing quality, and
completeness. The fallback debugging covers a lot more now, pointing
out new areas for improvement. Debugging toggles are now centralized in
exaPriv.h.
example of this is the root weave, which paints slightly slower on SiS
now in my testing. However, according to keithp some apps use this
feature for a sort of cheap backing store, which this could help with
significantly. While I haven't done much performance testing with it,
it will at least rule out one possible source of terrible performance.
chown/chmod later. Also disable by default on platforms that don't need
setuid root X servers (Darwin & SPARC's, according to
InstallXserverSetUID settings in the old Imake config files).
hook so we can upload a subset of a pixmap, and convert the current
drivers to respect that. Use this support to directly UploadToScreen in
exaGlyphs, providing a 47.4% +/-2.4% decrease in wall time for ls -lR
programs/Xserver in an antialiased gnome-terminal on an M6 (n=3, caches
hot). I would have bumped major version, only I can't tell what the
EXA_VERSION_* is supposed to be doing as opposed to the module version.
RADEONHostDataBlit.
- Disable the shortcut for switching from 3d to 3d in radeon_exa.c. It
appears that we do need the cache flush here, thought it's not clear
why. Disable the 2d to 2d shortcut while here, since I'm unsure of what
we're doing. Exposed by the following bit:
- Bug #4485: Add a new routine, exaGlyphs, to handle font drawing. Glyphs
were being accumulated in from non-migratable scratch pixmaps, causing
the destination pixmap to move towards screen but the migration
necessary for source never to happen, leading to abysmal performance.
Instead, copy the scratch glyph data into a real pixmap first, then
composite from that into the destination, allowing for migration. time
ls -lR from programs/Xserver showed 26.9% (+/- 6.3%) decrease in wall
time (n=3).
- Create exaDrawableUse* wrapping exaPixmapUse*, but which are aware of
windows needing backing store. Makes migration code prettier, and
ensures that composited windows will be migrated as normal when we turn
off cw for EXA. (issue brought up by keithp)
module for FreeBSD by setting some missing defines (XFree86Module,
IN_MODULE) in the dri directory. Note that those missing defines should
be somewhere generic, since there are other consumers of them, but I
haven't figured out where.
Define NO_SYS_HEADERS, as the monolithic build does. Helps FreeBSD.
Don't include validate.c in the library, since it seems to be a userland
test program.
around CPU access to the framebuffer. This allows the hardware to set
up swappers to deal with endianness, or to tell EXA to move the pixmap
out to framebuffer if insufficient swappers are available (note: must
not fail on front buffer!).
Submitted by: benh
LEDs match text console mode state. Move push of streams module earlier
so it's loaded before we start using kbd ioctls provided by the streams
module.
overridden at make install time.
Remove driverdir and inputdir from pkg-config file. The directory layout of
moduledir is fixed and well known by drivers.
loops, doesn't deal with failure, doesn't present the interface to
drivers that I expected) and instead replace it with a simple fallback
to software when coordinate limits could be violated. Act similarly in
other acceleration cases as well.
The solution I want to see (and intend to do soon) is to (when necessary)
create temporary pictures/pixmaps pointing towards the real ones' bits,
with the offsets adjusted, then render from/to those using adjusted
coordinates.