| Age | Commit message (Collapse) | Author |
|---|
|
Otherwise, with a pre-2.6.28 older kernel the disable would be lost at
resume time and cause hangs.
Bug #20214
|
|
The assumption is that we're almost always accelerating our drawing to
new pixmaps (fill, copy, etc.).
|
|
|
|
|
|
Forgot to update i915_video.c in 872aadc7102bd5131e1582ede081e22672911ba2.
|
|
|
|
We still pin the buffer object in case of overlay, but for textured video
we're now no longer using i830_memory for Xv anymore.
|
|
|
|
Wrong SDVO multiplier setup has been slipped
in SDVO TV patch. Thanks Michael Fu to point this out!
|
|
|
|
Found by Michael Fu for my last SDVO detect fix.
|
|
SDVOC detect bit is only valid for HDMIC.
And for SDVO devices, SDVOB detect bit should be used
to probe all possible SDVO outputs.
|
|
Which is just a hack to hide our SDVO detect drawback,
we will have SDVO/HDMI detect fix later.
|
|
Instead of set control bus switch before every i2c start,
just set once before doing DDC. This should eliminate some
encoders returning error during that.
|
|
As SDVO TV uses SDVO_TVClkIn from SDVO encoder for clock reference,
it needs to generate proper PLL for current input clock. This uses
fixed PLL table from vbios for this. And possible sdvo mulitiplier
has to be setup correctly. This makes TV output stable on my 945GCLF2
board with NTSC-M format.
|
|
|
|
They both needs parameters.
|
|
|
|
For SDVO DVI-I, check EDID info for digital output,
otherwise mark it to be disconnected as analog output
is driven by VGA then.
|
|
SDVO HDMI encode and audio is not setup in detect,
which fails in hotplug case for HDMI audio. Fix to
check current encode type and set flag for HDMI audio
enabling.
Check and set HDMI encode state in get_modes.
|
|
|
|
|
|
commit id b9f5915ce812144ffd9d2aa42e8ba856129c35e,
which resolved bug #17235, but generate new regression-bug #19715.
This patch intends to resolve bug #17235, and avoid regression as well.
We have successfully re-tested it for bug #17235 and #19715 respectively.
|
|
|
|
Missed the pI830->FbBase condition when removing the KMS hook.
|
|
Oops, my bad. Reverted 8d4bc36fae50b09a73ba2cfab920adb32141a358
since my kernel doesn't yet have the new param, committed
the revert by accident.
|
|
|
|
This adds back the resize hook so we can resize the front buffer under
kernel mode setting as well.
The patch also pulls the drmmode_* structs from drmmode_display.h into
drmmode_display.c and eliminates the header file.
|
|
This fixes failure to auth DRI2 clients under KMS.
|
|
Set alignments, tile settings and flags correctly in the 2D driver to support
tiled rendering. UXA's create pixmap function currently assumes the worst
about the alignment constraints; that should probably be fixed. Some of the
1M alignment fixes could probably be done more cleanly as well.
|
|
They're tiny so it shouldn't have been a problem, but play it safe. This is
another <5% loss on top of the previously reported value, bringing the whole
series to about 8%.
|
|
Several VBT modes out in the wild have H or VSyncEnd values greater than
the H or VTotal value. This clearly ends up creating a bad mode,
causing some panels to either ignore the timing or display some sort of
corrupt image.
Check for these cases and fix them up by default, making things work for
several Dell and Sony machines.
Fixes FDO bug #17292.
|
|
The IM-945GSE-A claims to have a TV output, and always claims a connected
LVDS output. It has neither.
|
|
|
|
This eliminates the pinned memory allocation for 965 render state.
|
|
|
|
This is a first step in a series of changes to avoid requiring a pinned object,
which gets in the way of doing non-root KMS. This change appears to result in
about a 2-6% loss in x11perf -aa10text, which better algorithms in libdrm could
make up for (it hasn't really had to deal with code this bad before).
|
|
|
|
Debian "unstable" is still stuck with this ancient version.
|
|
Leaving the VT in KD_TEXT mode keeps the kernel's blanking code active,
so when a DPMS event happens, the fb console is restored rather than X's
configuration. On the downside it means the kernel won't print messages
in the background, which would be visible if a panic or emergency switch
occurred. The proper fix here is a new kernel mode, which we can move
to when ready.
|
|
Even if KMS is enabled we should do this, to avoid running batches that
depend on other state we tear down in LeaveVT.
|
|
This improves performance by avoiding repeated map/unmap cycles, which are
a bit expensive on my machine with lock debugging on in the kernel. It could
do much better if we did more than 18 or so floats at a time.
|
|
The require_space had failed since it only checked for the space required
by the batch emits in the function itself, but not in the
i965_emit_composite_state() that it called (the state we were concerned about
having set up for that 12 * 4 dwords to follow!). This is replaced by
intel_batch_start_atomic(), which will catch such mistakes in the future.
|
|
|
|
Previously it wouldn't count the pixmaps that were about to be used, which
is pretty much the only purpose of having the pain around. This also
eliminates the check_twice confusion with emit_batch_header_for_composite().
|
|
|
|
|
|
We want the objects to be created once per prepare/done both for efficiency and
so we can handle aperture checking better.
|
|
This increases the overhead for video in the presence of cliprects, but we
were already doing nasty things in that case and don't seem to care. This
could fix potential bad rendering or hangs with video, particularly with
DRI2.
|
|
|
