This pre-GEM code was all sorts of broken -- see intel_bufmgr_fake.c for
the hoops that must be jumped to use that kernel interface successfully.
Yet we continued to use it even with KMS/DRI2/UXA, which may account for
some hangs.
People were trying to BEGIN_BATCH()/ADVANCE_BATCH() then i830WaitSync on the
results, which wouldn't necessarily wait and lead to various painful bugs,
since only EXA called MarkSync and only for certain rendering operations.
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.
This was blocked on wide distribution of X Server 1.6 (now in the current or
next version of major distributions) and solutions for a couple of significant
architectural problems (vblank sync and frontbuffer rendering, which we now
have code or good plans for).
This includes disabling XVMC which is DRI1-only currently.
In this path, we'd make it to allocator_init -> init_bufmgr without
GEM and without FbBase being initialized, leading to assertion failure
to catch this mistake.
Comedy ensued when trying to move just the MapMem up, leading to the rest
of the commit. Some day (like tomorrow after I rebase intel-cleanup) I'll
clean this path up.
Tested with 2 X Servers on 2.6.28 (one gets DRI2, one fails successfully),
2 UMS X Servers on 2.6.30rc2 (each gets DRI2), and 2 KMS X Servers on
2.6.30rc2 (success all around).
It's needed when KMS or DRI2 is enabled, or there will be memory leak.
Also fixes a segfault at startup with fake bufmgr.
Signed-off-by: Eric Anholt <eric@anholt.net>
If DRI2INFOREC_VERSION is defined in the server's dri2.h and has a
value greater than 1, compile to use the CreateBuffer and
DestroyBuffer interfaces. The format parameter parameter to
CreateBuffer is assumed to be the bits-per-pixel of the buffer.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
Before sdvo try to get edid by i2c bus, it must do switch control bus to ddc active state from sdvo only state.
However if current state has been ddc active state, redundant switch operation in our driver will cause error-
"Unable to write to SDVOCTRL_E for SDVOB Slave 0x70". The patch will do switch control bus only one time during
whole edid transmission.
It has fixed bug #19937
Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>
Tested-by: Ma Ling <ling.ma@intel.com>
Signed-off-by: Ma Ling <ling.ma@intel.com>
It appears the new chip doesn't support FBC currently.
Signed-off-by: Shaohua Li<shaohua.li@intel.com>
Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>
Signed-off-by: Zdenek Kabelac <zkabelac@redhat.com>
[anholt: renamed the member to match the variable name]
Signed-off-by: Eric Anholt <eric@anholt.net>
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>
This cleans up findstatic.pl output for the i830+ code, which resulted in
removing some code. The only odd part of this commit is the
if (0) i830_sdvo_dump() in i830_sdvo.c -- it tells the compiler that the code
is used, without using it since we want the code around while debugging.
It's also in a likely place to ask for the dump, so I think it's OK.
Note that pScrn->videoRam is an 'int'.
i830_driver.c: In function ‘I830ScreenInit’:
i830_driver.c:3019: warning: overflow in implicit constant conversion
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
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>
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
Kristian Høgsberg
Eric Anholt
Pierre Willenbrock
Shuang He
Alan Coopersmith
Ian Romanick
Zhenyu Wang
Shaohua Li
Zdenek Kabelac
Albert Damen
Julien Cristau
Robert Lowery
Carl Worth
Li Peng
Ma Ling
Jesse Barnes