In the past, the GTT has always been sized just large enough to map the whole
graphics aperture. However, apparently on the G965 that isn't the case, and
it is actually 512KB on hardware with a 256MB aperture. This resulted in X
not bothering to allocate memory for 256KB that it thought was already mapped
into stolen memory, and thus garbage rendering (particularly visible in large
video modes that displayed this unallocated memory). The kernel happens to
get the right answer by hardwiring a 512KB GTT size already, but that may not
be true on future hardware.
Instead, we use a convenient field in PGETBL_CTL that's specifically for the
GTT size rather than the aperture size, which gets us the answer we want.
This reverts commit 997e8c9bb4.
The GTT is definitely located at the end of stolen memory. This commit
apparently worked around mis-estimation of the GTT size.
This also replaces calls to compat code with the real names of the functions,
and slips #defines to an i830-namespaced version in when doing compat.
The current server version (7.1.99.2) is still left as requiring compat code,
since the version hasn't been bumped yet.
This also fixes some failures to call the compat code, and some failures to
actually compile the compat code. Oops.
Using pre-init computed RandR information, make reasonable
default choices for the output configuration at startup time.
Either some preferred size or a size which yields 96dpi is chosen,
from which other monitors are set to a similar size. The largest
size sets the screen size.
This needs to be extended to respect config file settings, but
those have not been defined yet.
RandR DIX code is preparing for xf86 drivers that want to allocate RandR
objects at PreInit time. This patch adapts to that change without taking
advantage of it.
Conflicts in PipeSetMode were resolved to use the keithp changes
that pushed more modesetting stuff into the per-pipe function.
Switched availablePipes to num_pipes.
Used modesetting default output configuration.
operatingDevices and MonType1/MonType2 duplicate information already stored
in the device structures. Eliminate them and replace uses with direct
references to the appropriate other data.
(cherry picked from 3ab7f96932 commit)
Also, remove setting of some other random registers that appears to have
been spammed in at the same time, and don't try to disable on the I830, before
this register existed.
DSPASURF/DSPBSURF can only take page aligned values, ignoring
the lower order bits. So, place the offset for the output
within the frame buffer in the DSPABASE/DSPBBASE registers instead.
Letting the ring buffer or other objects be allocated within the lowest
portion of memory appears to trash some memory mapping data; I'm assuming
this is the GATT table on the 965. Just marking this out of bounds for
allocation fixes this problem.
A few more register settings are needed to get CRT output working on the
965 chipset, in particular the the SDVO/UDI clock multiplier register
needed to get set to the default value (3). No, I really don't know what
this does, but it does get the CRT running at a wide range of sizes.
operatingDevices and MonType1/MonType2 duplicate information already stored
in the device structures. Eliminate them and replace uses with direct
references to the appropriate other data.
Eric Anholt
Keith Packard
Keith Packard
Keith Packard
Keith Packard
Alan Hourihane