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.
Convert all uses of PCITAG in int10 and vgaHW to 'struct pci_device'.
This allows the conversion of xf86ReadLegacyVideoBIOS and
xf86MapDomainMemory to 'struct pci_device' from PCITAG.
It builds against 1.4.7 as well, but it hardcodes the GLX_EXT_tfp tokens that
were finalized in 1.4.8, so GLX_EXT_tfp breaks if the client side was built
against an older glproto. This will hopefully alert people to rebuild other
components (in particular Mesa) against the new glproto as well.
Move the byte-order related wrappers out of the individual source
files into a dedicated header file. Modify the single hand-coded
source file that uses the byte-order wrappers to use the new header
file.
- Use autoconf tests instead of platform-specific #ifdef's to decide
which macros to use.
- Provide fallbacks for platforms like Solaris that don't provide any
of the existing known forms.
Events and internal data structures need to be updated whenever the physical
or pixel size of the screen changes. The code was ignoring the physical
size, so changing only that would not be registered anywhere.
(cherry picked from f42e3cea23 commit)
The RRScreenSizeSetRange function is used externally for 1.2 API drivers,
but can also be used in the 1.0 compatibility code. This also ensures that
the right changed bits are set so that clients are correctly notified when
the range changes.
RRGetInfo can return an error, use that to return BadAlloc to clients
instead of blindly going on with various requests.
(cherry picked from f05dd384d3 commit)
The fbdev API doesn't allow setting the pitch explicitly, so we have to set
the virtual width to the pitch we're using for drawing. This fixes corruption
after changing the virtual width with RandR.
The fbdev API allows the driver to 'accept' modes it doesn't really support by
modifying it to the nearest supported mode. Without this check, e.g. vesafb
would appear to accept all modes, even though it actually can't set any modes
other than the bootup mode at all.
This has been what has been used the most successfully post-damagetrack.
The current thinking is that:
1) We should be able to accelerate basically everything. So we don't need to
try to migrate trees of pixmaps permanently out of framebuffer to speed
CPU drawing up.
2) Migration is cheaper in the thrashing case, so we don't want to go to a lot
of effort to try (and fail badly) to find a working set.
