| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
(cherry picked from commit fd060ce89d86f6e8ff742d5b287abe8ecea32927)
|
|
(cherry picked from commit 577c4d1a0c753fb46d43be05a9781d2e204fac45)
|
|
(cherry picked from commit 7defa4f1f0eba82f39e74f96d2ad7ed2481b537e)
|
|
Previously, we were attempting to give both planes equal space in the FIFO
to be fair. However, larger modes require more fifo space, so split it based
on the relative HDisplay of the modes. This should resolve some fifo underrun
issues with differently-sized displays, or single large ones.
Bug #16169.
(cherry picked from commit b8ca1c747a679c931267363639fc0bc690cae2d6)
|
|
(cherry picked from commit c4565a9811487402d899d0933cc63e27ffe1ff08)
|
|
(cherry picked from commit 5054a86b1b362f3f63310afb9ef2d37c9f1cfca5)
|
|
(cherry picked from commit a34a4e3f6420e2b06bbdaa124fe0ccb1bc6a0bd9)
|
|
(cherry picked from commit 37661d916e8384f537d5ed8cbec66a93795c6a05)
|
|
Now, SDVO is only probed if the SDVO detected bit is set. If the SDVO probe
fails, but the detect bit is set, assume that it's an HDMI output.
(cherry picked from commit 65ad29d78793c7804f133a58de80ffaa0404ca28)
|
|
(cherry picked from commit beba1dd3561e38573ed9f507328caf7f8fb9f84a)
|
|
(cherry picked from commit 1cfe769c74d1a3a392bf1aaaf5c2dcc8273daf66)
|
|
This should improve behavior in the presence of VT switching, but also avoids
a crash on X exit from writing the register after unmapping mmio.
|
|
|
|
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.
|
|
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.
|
|
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+
|
|
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.
|
|
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.
|
|
Dell Latitude D500s seem to have this problem. At lid close/open, the DSPABASE
reg gets reset to 0, so we either need to keep the framebuffer at offset 0 or
make sure we reprogram the CRTCs after the lid opens again. Since we can't
make sure the former is always true (buffer resize, etc.), this patch adds a
quirk to reset the modes at lid open time.
Fixes FDO bug #14890.
|
|
This simply moves code from the driver up into the X server; use it where
available.
|
|
Mmap from /sys/devices/pci* on linux forces the cache-disable and
write-through bits, which turns our write-combining map into an
uncached-map, seriously impacting performance. It turns out that a bug in
mprotect allows us to fix this by disabling access to those pages and then
immediately re-enabling them.
|
|
pI830 may point to NULL if I830PreInit fails
|
|
This reduces the CPU overhead of memcpying them in every time, for a speedup
in aa24text of around 30%. This is based on work by Carl Worth which is
in the intel-batchbuffer branch.
|
|
The Intel driver appears to be coded to only work with displays
expecting 18 bit pixels. However I have an application using a LCD
display that expects pixel data in 24 bit format. The difference is
only 2 bits in a single GPU register. This patch implements that
change, controlled by a new driver option, "LVDS24Bit". The default
value is false, which is the previous behavior. When set to true,
then 24 bit panels should work (at least the one I'm testing here
does).
Fd.o bug #15201
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
|
|
It's gone, really.
|
|
The new chips no longer automatically flush the rendering cache, so if we
don't flush the RC at blockhandler, the last rendering done may not
appear on the screen. This was particularly noticable with a bare Xorg with
some missing root weave, and terminals where the last character wouldn't
appear until the cursor blinked. A flush in the DRI blockhandler path had
hidden this issue for most people.
|
|
unbound."
While I still like the idea, the mprotect calls themselves are failing on
Linux and causing more trouble than they're worth.
This reverts commit a1612b7728d4153499fe86b6713a13c8702cc7d9.
Conflicts:
src/i830_driver.c
src/i830_memory.c
|
|
Besides our driver having fallen through to the GM965 path for
RENCLK_GATE_D1, the BIOS was turning some of these on. It may be relevant
for previous platforms as well to zero out the fields that should be zero
in the other registers.
|
|
|
|
Default XvMC to disabled.
|
|
Move some declarations and don't declare an extra variable with the
same name, to fix warnings about mixed declarations and code.
|
|
Using the new interface allows the server to avoid some flicker at startup.
|
|
|
|
|
|
Unbind and bind a DRM BO may change the buffer offset, thus
crtc may reference a wrong rotated memory after a VT switch cycle.
Destroying it here will cause its reallocation when entering VT.
|
|
|
