| 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>
|
|
- field/frame timing log output now configurable per SF_Debug Xserver option
- odd numbers will output a status line every second
- even numbers will only spawn a line if a given value is exceeded either
drift or by sync point or by both
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>
|
|
- fast processors require additional delay of 32usecs where we wait for even field to pass
- white space fixes/indentation
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>
|
|
- the intel part of the patch did undergo a major rewrite for improved D945GSEJT support
- full compatibility to prior intel hardware maintained
- in the course of that the debug facility has been improved
Signed-off-by: Thomas Hilber <sparkie@lowbyte.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
- support for Intel D945GSEJT (Johnstown) included
- support for Asus Eee PC 701 included
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>
|
|
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>
|
|
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Thomas Hilber <sparkie@lowbyte.de>
|
|
In preparation for the 2.7.1 maintenance release.
|
|
Just changing the wording to turn 2.7.0.901 into 2.7.1.
|
|
The xorg-announce list doesn't need to hear about development
snapshots and release candidates. The intel-gfx list is good for
that.
|
|
Which means this is the first release candidate in preparation for 2.7.1.
|
|
There are some nice bug fixes here.
|
|
The spec says this command takes an extra (mbz) 32-bit value, so let's
provide it with one.
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit ed492131c13715b73c14d328d0668120acb58b40)
|
|
If a virtual display with width > 2048 is used, the first time
an XV buffer is needed will result in a BadAlloc error message,
but the next time X would crash.
Signed-off-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit d7ca870e1ce251d42e3689a8e1e7d080ab1325fb)
|
|
i915 textured video commands are quite long, but must be contained in the
same batch buffer as the 3D setup commands. When the number of clip rects
for the video becomes too large for the associated commands to fit in the
same batch buffer, this change breaks the sequence into pieces, ensuring
that each batch contains the necessary setup sequence.
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 8255cca2c9092f7ecb798944aa8f03fa3efcfa6c)
Conflicts:
src/i915_video.c
|
|
The optimization of unreferencing the binding table when the relocation is
posted causes the object to be dereferenced for each box in the clip list,
causing general chaos in the buffer manager. It's easier to just hold a
reference to the object until all of the boxes are painted and then drop it.
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 11a853bd8e5d907fe7f5bd907453bcdac9032861)
Conflicts:
src/i965_video.c
|
|
intel_batch_start_atomic takes an argument in 32-bit units, and so it must
multiply that by 4 before passing it to intel_batch_require_space, which
takes an argument in bytes.
We should figure out what units we want to use and use the same everywhere...
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 1142353b487c155a31011923fbd08ec67e60f505)
|
|
This gets output properties from kernel, then hook them up
for randr. So we can control output properties through randr
like in UMS.
Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>
|
|
Thanks to Gordon Jin for these suggestions.
(cherry picked from commit 73c3be1aa033e8c5c7ee777eb2fd43c19668fa86)
|
|
We've added a NEWS file now, so that needs to be updated for each release.
We're also now using tag names of just <version> rather than
xf86-video-intel-<version>.
(cherry picked from commit 3fd5a1ecd1d5140ae07ccc279298bcadd515e97f)
|
|
Hoping to cut off some false bug reports here.
(cherry picked from commit e1cace16a6130dcdd93965d2329a349d49200fa6)
|
|
In preparation for new major release.
|
|
These new files don't do us much good if we don't distribute them in
our releases.
(cherry picked from commit 9ffd1951d1f2fd2f53273d04ea29de050f07af55)
|
|
It will be nice to have release-notes under revision control, as well
being able to document issues in an obviously time-sensitive file,
(as opposed to README where we were documenting some of this previously).
(cherry picked from commit e4cd9de2933ada3e2a4b43552729ae3a370128bf)
|
|
Stale documentation considered harmful of course.
(cherry picked from commit 506c810f8f3db89048dda9777902f142ffeb86aa)
|
|
This is a sorted list of everyone with more than 2 commits in the git
revision history. We also list some historical authors mentioned in the
man page, (with code presumably pre-dating the beginning of revision
history).
(cherry picked from commit b9716b836cb2b4569c90b81f344932ac668dc5bf)
|
|
This was all very stale, and is better convered in intel.man. We replace
this with a list of pointers to where to get current information, (man
page, web site, and mailing list).
(cherry picked from commit 8deb3a3709a9aaa549be404566715a01246354d9)
|
|
This code disabled front buffer tiling in KMS. Turn it on since kernel
handles all tiling now, this improves performance of x11perf -aa10text
from 97k to 286k on my 945GME.
Should help with #20761, if not totally fix it.
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Li Peng <peng.li@intel.com>
(cherry picked from commit 9b615a52671aacf34666f90ecfff98651ce6afe2)
|
|
(cherry picked from commit 053432991c812146f6e7c6f13c6ace55385c825f)
|
|
(cherry picked from commit 62ba7211fe9b6aada125ebfe34cf7161e817ad6b)
|
|
Almost all digital TVs accept broadcast RGB values from 16 to 235 for each channel,
otherwise for those uncompensated videos, when RGB values are set from 0 to 255,
they will shows black and whiter clamping, which seriously degrades picture quality.
The patch will enable the broadcast RGB mode for hdtv according to user's setting.
It fixed bug #14486
(cherry picked from commit 69388953ce889080d5f014123d89bf3eb45f3d8d)
|
|
Thanks to Jesse Barnes for the original recipe.
(cherry picked from commit 6d345c49f693cc5cffaa00b94559d2afcb3a0864)
|
|
|
|
If we enable kernel execbuf fence register management, it's best if the
kernel manages all fence registers. This works fine if the accel
method is managing pixmaps or doesn't use offscreen pixmaps. However
with EXA, pixmap accesses are done relative to the framebuffer BAR
mapping (pI830->FbBase) and the Screen pixmap address. So if we try to
set the screen pixmap to point at a GTT mapped (and therefore properly
fenced) address, later calls to intel_get_pixmap_offset() will call
into EXA, which will use the pseudo-random pixmap addr and the EXA
offscreen base addr (which is really just FbBase) to calculate the
offset. This will fail. So disable kernel fence reg management in the
EXA case (this is easier than adding proper EXA pixmap management to
xf86-video-intel, and makes more sense since we'll be removing EXA soon
anyway).
Fixes FDO #21027.
Also happens to fix FDO #21029 (as tested by Carl Worth <cworth@cworth.org).
(cherry picked from commit 620e97bbd6a811ad69b8ac94df1fe2c9edf65549)
|
|
Since the change to scan-line based video sync, (rather than vblank-
based), we've only been getting tear-free video on one of the two
pipes. This fixes that bug by using the correct constant for waiting
on PIPEA.
(cherry picked from commit 0a0731c11d10392cdc55ecc04e4e3575c8b3fe57)
|
|
Since we're not limited by a single overlay plane on a single pipe,
we want to not clip at all, (so that the correct video appears on
both pipes).
This fixes bug #20980 which shows a video spanning two pipes
being rendered incorrectly.
(cherry picked from commit 940c2aad4d174b6609bdc49f8c99a4bc37926516)
|
|
fix bug #19529
(cherry picked from commit 63b4b5efac936c674dedad8125a8dbac4f000908)
|
|
We need to account for a non-zero Y offset for the CRTC. Without
this, we don't sync to the correct region, so tearing becomes
visible again.
(cherry picked from commit 5d9d9a2e466474a0508a15b294a91507ccb3ccc1)
|
|
construct function to find precise parameters from internal spreadsheet
table on G4X platform.
Signed-off-by: Ma Ling <ling.ma@intel.com>
(cherry picked from commit 7c94227dd4fa2164bebb36234958053bf1d26c12)
|
|
These timings on G4X platform were specified by internal spreadsheet from the chipset group.
Signed-off-by: Ma Ling <ling.ma@intel.com>
(cherry picked from commit 48db5bde9298f1126dfb42f4be8a3d61166abfd8)
|
|
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.
(cherry picked from commit 3d4ee3cac1d63dfdf7b54c8ba577f3b77637499f)
|
|
Either way, the goal is tear-free video playing. But waiting for
a scan-line window not only has the advantage of being cheaper
for small windows, but also avoids hanging the GPU in the case
of the pipe getting turned off, (by screensaver, for example),
while a batch is waiting for a VBLANK that will never occur.
This fixes that GPU hang.
(cherry picked from commit bc3312fd7c03d09a231dfebfe390fe668ad15d1e)
|
|
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)
|
|
Found by Hugo Jacques <hugo.jacques@verint.com>
(cherry picked from commit fad714c40078d22fff82dc0692a344f66ddf9680)
|
|
(cherry picked from commit 00de1757dd5776962bdd4c8968181878c2ebf4c9)
|
