Lower level functions will destroy objects that are managed by the DRM
allocator, so make sure those are done before the allocator shuts down.
Signed-off-by: Keith Packard <keithp@keithp.com>
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>
The lower level close screen functions will free allocated objects, causing
a crash if the allocator isn't still available.
Signed-off-by: Keith Packard <keithp@keithp.com>
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>
There's no reason to clip cursor positions to an artificial limit; the
hardware cursor limits always mirror the hardware display limits.
Signed-off-by: Keith Packard <keithp@keithp.com>
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.
Keith Packard
Carl Worth
Kristian Høgsberg
Eric Anholt
Pierre Willenbrock
Shuang He
Alan Coopersmith
Ian Romanick
Zhenyu Wang
Shaohua Li
Zdenek Kabelac
Albert Damen