The server may have made a DPMS call before doing rotation, so after we
do the mode set with the rotated framebuffer, we need to re-enable the
corresponding output(s).
Fixes bug #20573.
Since we added the pipe A force quirk (leaving pipe A on all the time),
DPMS calls to disable it have silently returned, leaving the pipe on.
If another driver (like vesafb) has enabled it, we may end up with a bad
configuration, leading to hangs or blank screens at VT switch time.
Fixes bug #19603.
With glyphs sitting in per-glyph pixmaps, there's no reason to use the CPU
to move them to the cache pixmap, and lots of reasons to use the accelerator.
Signed-off-by: Keith Packard <keithp@keithp.com>
EXA doesn't support KMS, so force UXA on if KMS is detected. And warn
the user if they've specified something other than UXA in their
xorg.conf.
Fixes bug #20620.
This reverts commit ddedf19f88.
After i2c STOP, control bus will return back to internal
registers. So this brings back to origin code that we switch
to DDC bus before START. But it's ideal to only issue DDC
bus switch after STOP, not before every START, which might eliminate
some complains from SDVO device, that will be another patch later.
The XVMC AM_CONDITIONAL is only needed around the library expression.
None of the other definitons will cause anything to be built without
libXvMC, but they're needed for 'make dist'.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
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.
We should use preferred input timing's clock for correct
pixel multiplier setting, otherwise we might get inconsistent
multiplier setting on pipe and SDVO device for some modes.
Ideally we'd not be using the EXA offscreen memory manager and just hand all
that memory to the fake bufmgr for non-GEM, but the fake bufmgr's too slow for
that, at least currently. So compromise and take enough memory that it will
succeed at XV allocations but hopefully not anger tiny-aperture systems too
much.
Bug #20563.
We rely on having AGPGART present to successfully allocate video memory as
we configure it by default. Admit that fact, and remove support for
non-AGPGART/KMS setups.
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).
For SDVO encoder that advertise multiple functions,
we have to get attached display to determine current
output, and update output's name according with
current type.
This allows multiple X server to use DRI and makes it possible to run
multiple X servers under KMS. This requires a 2.6.29 kernel to work.
On older kernels it will just log a warning and DRI will fail to
initialize for the second X server.
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.
This is to fix bug #16566, change TV format will cause BadMatch
error when crtc config apply. Everytime when we change TV format,
we may generate a new list of modelines as TV clock changed. After
randr get info request, new modelines will be probed and randr output's
modes will be renewed too. But crtc's mode failed to be updated,
as it never can find a matching mode now within new modes list.
So get info will return an invalid crtc's mode, later set crtc
config will pass that info, and xserver catches a bad match.
This patch trys to refresh output modes and setup crtc's mode
with new modelines in TV format change. So get info would be
sure to turn valid crtc mode that reference in current new modelines.
This is the intel video driver patch for a new chip, which is G33-like
and has some clocking setting related register changes. This patch adds
the pci id and DPLx/FPx register changes.
The gtt tool should just work to me, as the chip hasn't any changes
against G33 on this side.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>