Age | Commit message (Collapse) | Author |
|
- now supports HDMI 1600x1200 50Hz interlaced resolution
- adjustment control now operates at lower speed which is still fairly sufficient
Signed-off-by: Thomas Hilber <sparkie@lowbyte.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Signed-off-by: Thomas Hilber <sparkie@lowbyte.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
- new scheduling option added
Signed-off-by: Thomas Hilber <sparkie@lowbyte.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
- introduced new xorg.conf options for both intel and radeon FRC patches
- FRC (aka sync_fields) switch (default on)
- process priority (default 0)
- FRC debug output (default off)
- intel Xserver now starts even with disconnected monitor
Signed-off-by: Thomas Hilber <sparkie@lowbyte.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
- Full functionality of Radeon based original patch now ported
to recent Intel graphics hardware. This includes support
for i945G chipsets as found on EEE PCs and D945GCLF[2] boards.
- Exploits some special features of i945G chipsets like
vertical phase registers and fine tuning of vertical scaling.
This enables us to compensate for interference effects observed
when driving modern digital displays through a SCART interface.
Signed-off-by: Thomas Hilber <sparkie@lowbyte.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Stale documentation considered harmful of course.
(cherry picked from commit 506c810f8f3db89048dda9777902f142ffeb86aa)
|
|
Don't use bo->virtual in the begin_gtt_access case, use the framebuffer
mapping and bo offset instead.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
(cherry picked from commit 6cd914ef315036ce8e91c7b6492994353e8ed2d8)
|
|
Hopefully this concludes the fixes necessary to deal with the various
combinations of kernel and user level tiling. We have several cases to
handle:
1) KMS (kernel handles all tiling)
2) UMS w/memory management + kexec fencing (kernel handles all tiling)
3) UMS w/memory mangement but no kexec fencing (userland handles tiling)
4) UMS w/o memory management (userland handles tiling)
For cases (1) & (2) we can use GTT mapping, which will give us good
performance and take care of allocating fence registers as needed. It's
important *not* to have userland set up fence regs in this case, since
the kernel will be using all of them.
For case (3), we use the begin/end GTT map functions provided by libdrm,
in combination with pinning and fence register setup in i830_memory.c to
deal with tiled surfaces. This also gives us good performance and
correctness.
For case (4) we use the old style virtual mapping + offset for dealing
with surfaces; note that UXA doesn't seem to work in this configuration
regardless of these fixes.
Fixes bug #20803.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
(cherry picked from commit 8dabcc40747bfd478f296728741240241698f165)
|
|
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.
(cherry picked from commit 73db44e7ac524e84e5f0fda2d60069a9e954ad1b)
|
|
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.
(cherry picked from commit 6deb26ae7bd796e88a5dd90df5f6c35fbc44e798)
|
|
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.
(cherry picked from commit 3ef9d85371a97ea5baee0c47787b3bb3cdaf5135)
|
|
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.
|
|
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.
|
|
It's been broken for years now, and KMS offers a much better chance of getting
this working sensibly without making a mess of the 2D driver.
|
|
|
|
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 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>
|
|
|
|
|
|
This was hit by xv86vm's SwitchMode path, and for that the CRTC offsets
get set at mode setting time anyway.
|
|
Otherwise, with a pre-2.6.28 older kernel the disable would be lost at
resume time and cause hangs.
Bug #20214
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
This also introduces tests to make sure that we asked for enough reserved space
and that we don't allow wrapping at the wrong time.
This fixes a hang during text rendering with DRI2 and a GL client running,
but could potentially affect text rendering with GEM in general with an
exceptional batchbuffer setup.
|
|
since modesetting is compiled by default now, ifdef __linux__ the linux
only includes and ioctls.
|
|
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Since we don't perform any synchronization with the kernel on these regs, we
could race with the kernel to write stale values and end up not having vblank
interrupts enabled when somebody was waiting on one.
|
|
|
|
This should be a noop. If it wasn't a noop, it means that on pre-g33 chipsets
we were spamming some data into a page of system memory because we used a
virtual instead of a physical address. It was also supposed to not work when
we submit it from a batchbuffer, as we have been doing for some time now.
This code has existed since about the beginning of the driver's existence,
with no justification.
|
|
|
|
Signed-off-by: Dave Airlie <airlied@linux.ie>
|
|
Don't miss classic texture memory allocation in DRI.
|
|
Detect bit of SDVOC is reserved on 965G/965GM, instead of ignore SDVOC
this trys to always probe it on these chipsets.
|
|
This avoids mapping a buffer object which is being referenced
by a batch that has already been flushed, (which is a terribly
expensive operation).
On my machine this brings the performance of x11perf -aa10text
from 85k back to 150k, (where it was before a recent kernel
upgrade). Also, before this patch, when I used my X server
actively performance would drop as low as 15k---hopefully that
bug is gone with this change.
|
|
|
|
|
|
|