| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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)
|
|
|
|
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>
(cherry picked from commit e031cc02e65acfbafb48136dad414751e04425c5)
|
|
|
|
They should be listed as lower case, since that's what you'd pass to xrandr.
(cherry picked from commit 52d6ced652059989e6d9780a149488ccd16e3a22)
|
|
Basic support for panel fitting.
(cherry picked from commit 05cf07071e25f84dec3476a9bed7235ed50cd249)
|
|
|
|
Conflicts:
configure.ac
src/common.h
src/i830.h
src/i830_debug.c
src/i830_quirks.c
src/i830_video.c
|
|
Default XvMC to disabled.
|
|
Conflicts:
man/intel.man
src/i830_driver.c
|
|
|
|
git+ssh://git.debian.org/git/pkg-xorg/driver/xserver-xorg-video-intel into debian-unstable
|
|
+ server leaves pipe disabled at shutdown / vt switch ; closes: #453374
+ [855GM] need to use BIOS for mode information ; closes: #437066
+ Intel 2.2 crashes if playing a video then switching to another desktop;
closes: #452372
+ [G33] 2.2.0 locks up X with error "First SDVO output reported failure to
sync" ; closes: #451917
|
|
On some platforms, the firmware may read & write GPU registers on lid close,
suspend/resume time or during various SMM events. If one of the graphics pipes
is disabled at that time, the GPU may hang due to the programming dependencies
of the various registers.
This patch adds a quirk to force the driver to keep pipe A enabled if
necessary, through user configuration in xorg.conf or via a platform specific
quirk. Leaving the pipe enabled comes at a power cost however, so the quirk
should only be enabled when strictly necessary.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=11432.
|
|
On some platforms, the firmware may read & write GPU registers on lid close,
suspend/resume time or during various SMM events. If one of the graphics pipes
is disabled at that time, the GPU may hang due to the programming dependencies
of the various registers.
This patch adds a quirk to force the driver to keep pipe A enabled if
necessary, through user configuration in xorg.conf or via a platform specific
quirk. Leaving the pipe enabled comes at a power cost however, so the quirk
should only be enabled when strictly necessary.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=11432.
|
|
|
|
|
|
Add descriptions for LVDS and TV output properties and also mention the EDID
property a new output configuration section.
|
|
|
|
This commit fixes backlight support for several platforms.
Except on recent machines supporting the IGD OpRegion specification,
backlight control is rather platform specific. In some cases, we can
program the native backlight control regsiters directly without any
trouble. On others, we need to use the legacy backlight control
register. On still others, we need a combination of the two. And on
some platforms, none of the above will work, so we go through the
kernel backlight interface, which provides a platform specific driver
for backlight control.
|
|
Conflicts:
configure.ac
src/i830.h
src/i830_display.c
src/i830_lvds.c
src/i830_memory.c
src/i830_quirks.c
src/i830_tv.c
|
|
|
|
|
|
|
|
Conflicts:
src/i830_dri.c
src/i830_memory.c
|
|
autoreconf and update changelogs.
|
|
|
|
|
|
Reported by A. Costa" <agcosta@gis.net> in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432061
(cherry picked from commit 0fd3ba0518b3cde9ca0e4e2fc1854c00d8a43d5c)
|
|
Reported by A. Costa" <agcosta@gis.net> in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432061
|
|
This is a step towards being able to expose buffer objects through the screen
private to DRI clients, instead of having them have to use the fake buffer
object type.
This fails in two ways. First, the kernel memory manager is not currently
suitable for doing the physical allocations we need, so we still use AGP for
those. Additionally, the DRI lock can't be initialized early enough for us, so
these buffer object allocations fail. This will be fixed by improving the
DRM interface.
|
|
|
|
|
|
|
|
git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel into debian-unstable
|
|
|
|
"true" in your xorg.conf). Should save ~0.5W during typical 2D usage.
|
|
|
|
|
|
debian-experimental
|
|
It had been necessary to allow more than a small amount of memory to be
allocated, but now those old small allocations people had configured are
getting in the way.
|
|
|
|
|
|
With the fixes to the 2D frame buffer allocation that allows up to 65536
lines of 2D frame buffer in XAA mode, the old linear allocation hacks are no
longer necessary.
|
|
|
|
Install it as an alias to intel.4x, since we're letting people load the driver
as "i810" still.
|
|
|
|
|
