implementation. Includes cache flushing to prevent bad first reads of
the framebuffer, fixing blending of many formats, falling back on many
unsupported operations, and falling back early to prevent migration.
Passes all of rendercheck except some of the blend (!) tests.
in the kaa structure: markSync and waitMarker. The first, if set,
returns a hardware-dependent marker number which can then be waited for
with waitMarker. If markSync is absent (which is the case on all
drivers currently), waitMarker must wait for idle on any given marker
number. The intention is to allow for more parallelism when we get
downloading from framebuffer, or more fine-grained idling.
- Replace the KdMarkSync/KdCheckSync functions with kaaMarkSync and
kaaWaitSync. These will need to be refined when KAA starts being smart
about using them. Merge kpict.c into kasync.c since kasyn.c has all the
rest of these fallback funcs.
- Restructure all drivers to initialize a KaaInfo structure by hand rather
than statically in dubious order.
- Whack the i810 driver into shape in hopes that it'll work after this
change (it certainly wouldn't have before this). Doesn't support my
i845 though.
- Make a new KXV helper to avoid duplicated code to fill the region with
the necessary color key. Use it in i810 and mach64 (tested).
- support for mouse-like devices that report absolute coordinates
- support for mouse-like devices that need to know screen size so they can
scale absolute coordinates to screen size
- fix 3-button emulation
DRIINFO version to match. Fix various pointer printfs in libdri to be
64-bit aware. Silence a warning about redefining noXFree86DRIExtension.
(Jesse Barnes)
number of the DRIInfoRec, disambiguating it from the XF86DRI protocol
version number. Modify DRIQueryVersion to return the libdri version
number, which all DDXes were requesting implicitly. Fix the DDXes to
check for the DRIINFO version they were compiled against.
standard mode solely determined by the mode ID or it may be a detailed
mode with almost arbitrary mode parameters. The mode parameters are
passed to the BIOS in a memory area pointed to by es:di. If bit 11 in
the video mode is set this memory area is evaluated. When we don't have
such an area (passed to VBESetVBEMode() this function should unset this
bit for sanity reasons. (Bugzilla #3329)
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).
<X11/...>
- For Xcomposite and Xdamage, don't link the build system out of the xc
tree
- Link the public X11 headers into their own directory
- Add links to XKeysymDB and XErrorDB
- Add links to all the Xlib man pages
- Add links to the lcUniConv subdirectory
- Conditionally include config.h in Xlib source
