Age | Commit message (Collapse) | Author |
|
So that you can indeed allocate a linear framebuffer if you so desire
without breaking mesa.
Adds:
Section "Driver"
Option "LinearFramebuffer" "False|True" # default false
EndSection
to xorg.conf
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 049ce4397ddf7fd088ce364cbb53cacf5133176f)
Conflicts:
man/intel.man
src/intel_driver.c
src/intel_driver.h
|
|
An attempt to workaround the incoherency in gen2 chipsets, we avoid
using dynamic reallocation as much as possible.
The first step is to disable allocation of pixmaps using GEM and simply
create them in system memory without a backing buffer object. This
forces all rendering to use S/W fallbacks.
The second step is to allocate a shadow front buffer and assign that to
the Screen pixmap. This ensure that the front buffer remains in the GTT
and pinned for scanout. The shadow buffer will be rendered to in the
normal fashion via the Screen pixmap, and be marked dirty. In the block
handler, the dirty shadow buffer is then blitted (using the GPU) over
the front buffer. This should completely avoid having to move pages
around in the GTT and avoid incurring the wrath of those early chipsets.
Secondly, performance should be reasonable as we avoid the ping-pong
caused by the small aperture and weak GPU forcing software fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
(cherry-picked from commit 2b96c18165d713cd6781dbf217ec33e11cc961bc)
Also pulled in the following commit:
commit ae160d7fbfc79e78dad8702efcc55d9c0c25ff67
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Sep 10 13:19:12 2010 +0100
shadow: Simply modify the Screen pixmap header
This is a slightly less risky strategy than having to remember to update
all pointers to the old Screen pixmap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Use MAN_SUBST now supplied in XORG_MANPAGE_SECTIONS
The value of MAN_SUBST is the same for all X.Org packages.
(cherry picked from commit 2d85efaa36791bd441f069b612ee86387353d1ed)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
(cherry picked from commit 6e61de896b42cffe1af6b0384cb69265d3d121a1)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
These were added in 3c0815abf28744e215bea286e71d935cd486955a . The
documentation added here comes straight from that commit message.
(cherry picked from commit 88b2209a7526a7c7f3b3a2d491d48bd0d5d56e04)
|
|
The NoAccel option is not valid for other chips.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Until we get triple buffering, we'll want this so users can avoid taking a
performance hit on apps that render slower than the refresh rate.
Fixes fdo bug #22234.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
UXA has completely replaced EXA at this point. UXA is the same rendering
core as EXA, but relying on kernel memory management or a fake bufmgr instead
of trying to manage memory in the X Server.
|
|
While EXA/UXA aren't completely good replacements (see bugzilla for
performance and stability problems), we are pretty sure at this point that
it's the right way to go and that having multiple acceleration architectures
is getting in the way of producing a stable codebase.
|
|
Stale documentation considered harmful of course.
|
|
|
|
We previously had a heurstic here where we would only sync to vblank
for windows that covered more than 25% of the screen. We don't need
this anymore since the new approach to sync, (WAIT_FOR_SCANLINE_WINDOW),
is not excessively costly for small windows.
|
|
The i810 compatibility symlink has been broken since libpciaccess, so just
let it die.
|
|
In order to bypass failure in TV load detect, TV_Connector option
will always force TV as connected with user specified connector type.
|
|
With this change, we always expect the 3D driver to use GEM textures
when the 2D driver uses GEM. When GEM is not available or disabled,
we fall back to legacy fixed textures.
|
|
|
|
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
The groff .IP macro is used to put the option defaults in a new indented
paragraph so they are separated from the explanations.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
[anholt: hand-applied due to conflicts. mistakes are my own]
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
google shows one instance of this being used a year and a half ago.
|
|
Any time we actually need SW cursors, it gets enabled automatically.
|
|
Add an Xv attribute XV_SYNC_TO_VBLANK which has three values -1(auto), 0(off)
and 1(on) to control whether textured adapter synchronizes the screen
update to the vblank. The default value is -1(auto).
|
|
This is based on Jesse's origin patch for bug #12763.
But export integer range to user instead of hardware float
point format, and fix different real format on 965G and 945G
for contrast and saturation.
|
|
This can let user override non-stable driver TV load detect,
and set connector type manually, e.g for s-video to component
converter, this patch seems must needed to use HD modes.
|
|
Which is just a hack to hide our SDVO detect drawback,
we will have SDVO/HDMI detect fix later.
|
|
It was broken on current kernels, and deprecated anyway.
|
|
It never worked with any upstream linux kernel, and is quite heavily
deprecated. A new solution based around DRI2 will probably be
forthcoming. Pageflipping itself is next.
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Keith Packard <keithp@keithp.com>
|
|
Some ADD2 card doesn't get SDVO detect status setup right,
which disabled outputs on those cards. This adds a new
option "ForceSDVODetect" to probe all SDVO ports anyway.
|
|
|
|
|
|
|
|
Add example dual head config, add info on bug reporting.
|
|
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>
|
|
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>
|
|
|
|
They should be listed as lower case, since that's what you'd pass to xrandr.
|
|
Default XvMC to disabled.
|
|
Basic support for panel fitting.
|
|
Conflicts:
man/intel.man
src/i830_driver.c
|
|
|
|
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:
src/i830_dri.c
src/i830_memory.c
|