| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This reverts commit 0c00a638ef57aa9d6a3047176b0bfad733f781f0.
Those FIFO watermark regs are 945-ish, and cause problem
on G35.
(cherry picked from commit 740a73dad1d9a9b0ebf1cc7d6f2a056abad57aaf)
|
|
(cherry picked from commit e9532f3abf1e0b62b2569d4aae60a5a63add571f)
|
|
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.
(cherry picked from commit 5103e5a39a4869a714b8a59da8bf51ecc8c65e4f)
|
|
The XVMC code uses a magic FOURCC code to signal frame updates, but that
code is only defined when the XVMC code is used.
(cherry picked from commit 18ef4158e5574bfc6621b268821532f13e261d13)
|
|
(cherry picked from commit 6366e4de540c4713cbc8402c89516464bbdc35b9)
|
|
|
|
|
|
|
|
Seems not resolve the issue (fdo bug #15885).
(cherry picked from commit f280c50dd5d29c5717adc6da2368363cb3d0adbb)
|
|
(cherry picked from commit d91d9e6a2f2ba18b35cb6fd7bc3fe8bc617eb44f)
|
|
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>
(cherry picked from commit 9f324860431ff8199a78d19bbaa74046e1476b89)
|
|
There are lots of good reasons for doing this, one of them is fdo bug #11305.
(cherry picked from commit 33f033cbf346c13a687e469e8879579fcd5bb2fb)
|
|
(cherry picked from commit a7188b1f2dd9a69fa7daefe478d283735226f9f3)
|
|
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.
(cherry picked from commit 36ec93300926084fb2951d69b001e4c67bc6ff79)
|
|
(cherry picked from commit 0c00a638ef57aa9d6a3047176b0bfad733f781f0)
|
|
Don't check xvmc lib if user has already wanted to disable it.
Fix fdo bug #15762.
(cherry picked from commit c81a4687fca80bf7367d7f0e9a00a6a09737c5bb)
|
|
(cherry picked from commit be746a90a87d7a9807fa4243493e7e4d48f7f1c0)
|
|
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.
(cherry picked from commit a0ced923bb793aa22e6bfbeeec0888d3b42ce176)
|
|
This simply moves code from the driver up into the X server; use it where
available.
(cherry picked from commit fff17b9d1b58cb53032d153094826dd306836d59)
|
|
I830PutImage was checking to make sure the target pixmap resided in video
memory, but this isn't necessary when using the overlay. Test
(cherry picked from commit 1d467a8038946a37844795e8860be113d43219ac)
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
debian/changelog
debian/control
|
|
|
|
|
|
|
|
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.
(cherry picked from commit c3fb62df4e60b63295f94c99b3c5de70dbf94e1c)
|
|
2D pitch limit applys to all chips. Pre-965 chip has
8KB pitch limit for 3D. 965 supports max pitch by current
exa (128KB).
|
|
This reverts commit 602613e397bdf0cf701a6a7748f9343875864466.
Pre-965 chipset actually have different pitch limit for 2d and 3d
engine. For 2D blit, it's 32KB max. For 3D, it's 8KB max. Don't
limit it to minimal which fallback 2D operations (noteable copy
slow).
|
|
|
|
pI830 may point to NULL if I830PreInit fails
(cherry picked from commit 0ae283582d21776d3317d5fc1c25751d50d562c7)
|
|
|
|
|
|
|
|
Conflicts:
debian/changelog
|
|
i8xx currently only works in FULL mode.
|
|
2.3-rc3
|
|
Fix distcheck
|
|
This reverts commit f47486fab3dffcbb03e7ad89f777abba1e887299.
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.
(cherry picked from commit da85d1b822dcb31698e9c5ab85a7bb27ad745eee)
|
|
It has never been used, and that doesn't look likely to change.
|
|
|
|
Drivers reference symbols from /usr/bin/Xorg and other modules, and
that's not a bug, so we want dpkg-shlibdeps to shut up about symbols it
can't find.
|
|
|
|
intel-gen4asm doesn't allow '#' line
(cherry picked from commit f47486fab3dffcbb03e7ad89f777abba1e887299)
|
|
(cherry picked from commit 5c9cde37e769287fb7bf4e08c3600a33c2e92dce)
|
