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>
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.
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.
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.
The gen4_render_state is now always called "render_state" (i965_render.c
bookkeeping) and gen4_state_t is now always called "card_state" (the buffer
for state used by the chip).
This patch duplicates all of the surface sampler state needed to read from
the separate YUV surfaces and then has the planar sampler read from samplers
0, 2, 4 instead of 0, 1, 2. This appears to make things work, instead of
having the samplers break at random. I do not understand why this works.
We have a collection of wm_state objects for each ps kernel,
(one for each combination of src and mask extend and repeat
values).
Thanks to Dave Airlie for noticing an errant write through a
wild wm_state pointer in an early version of this commit.
(cherry picked from 7763706a93d3021907273f9b330750ba110e2fc3 commit)
This cherry-pick required more reformatting than most, due to the
projective texturing merge.
This will eventually allow for the elimination of sampler state
updates while compositing---and initializing everything in the
initialization function.
(cherry picked from commit d0874697be8086cd64740c24698df8cd4d31c76f)
This reverts commit f47486fab3.
Sorry for failing to push the #line processing changes to intel-gen4asm;
those are now pushed, so this change should no longer be necessary. Having
correct file name and line numbers in the error messages is awfully nice
though.
We need one for each possible combination of src and dst
blend_factors. Again, as with recent changes, this eliminates
state updates from prepare_composite and allows that function
to instead simply reference an existing object initialized
within gen4_state_init.
Thanks to Dave Airlie (and git-bisect) for pointing out that with
gnome-terminal all text was appearing as solid black with an early
version of this commit. As expected the bug was an alignment issue.
(cherry picked from 0c0ab52c2d100c47f38c7ef826ef585c8b9815e9 commit)
Performance is approximately equivalent on text tests, but may be
around +2%.
The YUV->RGB code was written to write directly to the dataport registers,
but that didn't work for the compositing functions (cause still unknown).
This change makes that code write RGB values to the src_sample registers as
with the other sample computation fragments.
This reverts commit 346cf57deabb4c336612df4c13650a87b5ef6775.
Mixing randr transforms and video caused screen corruption for Render
operations. No, I don't understand why.
The hardware has been marked as needing a sync, so the next video put will
block waiting for the previous one to complete. Adding a sync here just
stalls the video playback for no good reason.
Bryce Harrington
Zhenyu Wang
Mike Isely
Jesse Barnes
Eric Anholt
Jesse Barnes
Keith Packard
Hong Liu
Carl Worth