Age | Commit message (Collapse) | Author |
|
|
|
|
|
The bit set is now reserved -- used to be a workaround for early revisions.
|
|
|
|
We want these to always be set when our driver's in control. They are
already appropriately save/restored at leave/entervt.
|
|
|
|
|
|
|
|
|
|
|
|
Besides not being #ifdef __linux__ed as requested, some linux kernels break
in exciting new ways when you try to mprotect from PROT_NONE back to
PROT_READ|PROT_WRITE. Yes, there are bugs in the code we're calling in a
bug-exploiting bug workaround.
If you want this workaround for the original bug exposed when moving to
libpciaccess, it's already in libpciaccess.
|
|
Fix fd.o bug 15766
|
|
From the spec, only 965GM and IGD_GM have 128 FIFO entries.
With DSPARB change introduced by commit bd137a, I've got PIPE B
underrun when dual-headed on G35 platform.
|
|
|
|
|
|
Also safe check context size to not exceed surface max.
|
|
|
|
It turns out 855 has a different DSPARB layout than 915+. And 945+ have more
FIFO entries, so we have to allocate things differently. So on 855 split the
FIFO evenly again between A & B planes, and do the same on 945, where we have a
larger FIFO. Fixes an issue reported by Daniel Stone with the previous default
value.
|
|
|
|
What I originally checked in was a bit misleading.
|
|
Add some debug code to catch FIFO underruns, which are normally bugs (unless
they occur during mode setting) and remove any plane C FIFO allocations, since
we don't use that plane at all. We may eventually need to be a little smarter
about this on platforms that use plane C for the popup.
|
|
Update clock gating disable bits to match docs and allocate a power context
memory area so that newer chips can save state and power down the render unit.
|
|
|
|
|
|
This reverts commit 53e3693ef13f31f3fc33bcff7286ab2b03b2d430.
Conflicts:
src/i830_driver.c - default FBC on for 965+
|
|
This reverts commit 0c00a638ef57aa9d6a3047176b0bfad733f781f0.
Those FIFO watermark regs are 945-ish, and cause problem
on G35.
|
|
|
|
|
|
|
|
|
|
|
|
allocate → create
unreference → close
name → flink
|
|
GEM needs memory alignment requirements sent at pin time, which is a bit
after the allocation itself. Store the required alignment in the memory
object for later use by pin.
|
|
In full_aspect mode, we try to preserve the aspect ratio by adding
either top & bottom or left & right borders. In the letterbox case (top
& bottom borders) we were miscalculating the top border which led to
programming a bad mode. Fix the calculation and bug #15559.
|
|
Seems not resolve the issue (fdo bug #15885).
|
|
|
|
Depend on value returned by function within assert is wrong.
Fixed weird render corrupt on i965.
|
|
The Intel xorg driver tries mightily to determine the native fixed
panel mode settings for the LVDS output. It does this through various
means, including scanning video BIOS tables, and noticing if the pipe
in question has already been set up by somebody else (and adopting
those timings). This strategy works well for say a laptop where the
LCD panel is an integral part of the machine. But for other
applications where the display is unrelated to the system's BIOS or
other software, then the BIOS will likely have no clue how to
configure the LVDS output. Worse still, the BIOS can simply "get it
wrong", leaving the pipe misconfigured. Unfortunately the Intel
driver can potentially notice this, adopt the same settings, leaving a
messed up display.
All of this complexity normally happens independently, behind the
scenes, from the mode timings that might otherwise be specified by the
user. This driver has a concept of fixed, i.e. "native" mode, and
then user-specified mode. If the corresponding resolutions between
those concepts don't match, then the driver in theory will arrange for
scaling to take place while adhering to the actual native mode of the
panel. Said another way, if the user says 800x600 but the driver
mistakenly (see above) thinks the native mode is 640x480, then 640x480
is the mode set with scaling to an 800x600 frame buffer. If the
driver gets the wrong native mode, then the result is a miserable mess
with no way for the user to override what the driver thinks is right.
This patch provides a means to override the driver. This implements a
new driver option, "LVDSFixedMode" which defaults to true (the normal,
probe-what-I-need behavior). However when set to false, then all the
guessing is skipped and the driver will assume no fixed, i.e. "native"
mode for the display device. Instead with this option set to false,
the driver will directly set the timings specified by the user,
providing an escape hatch for situations where the driver can't
correctly figure out the right mode.
Under most scenarios of course, this option should not be needed. But
in situations where the Intel video BIOS is hopelessly fouled up
related to the LVDS output, this option provides the escape hatch for
the user to get a working display in spite of the BIOS situation.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
There are lots of good reasons for doing this, one of them is fdo bug #11305.
|
|
|
|
2D pitch limit applys to all chips. Pre-965 chip has
8KB pitch limit for 3D. 965 supports max pitch by current
exa (128KB).
(cherry picked from commit 8187a5a16f8bd8f0ba5e7f5357f355928b3b8f07)
|
|
The fix for flushing at blockhandler with no DRI on 965 was broken and would
try to flush the chip even when the driver wasn't in control of the VT.
Hilarity ensued.
|
|
|
|
Don't check xvmc lib if user has already wanted to disable it.
Fix fdo bug #15762.
|
|
|
|
|
|
|
|
|
|
|
|
non-965 tiled frame buffers have fairly strict alignment requirements, 512K
on 8xx and 1MB on 9xx, plus they must be aligned to the size of the
allocation.
|