| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Rémi Cardona <remi@gentoo.org>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
XF86DRI is defined by the SDK so not defining it here just breaks the
build. Define HAVE_DRI instead to avoid collisions.
Note: DRI2 is still enabled/disabled entirely by SDK defines.
Signed-off-by: Rémi Cardona <remi@gentoo.org>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Bug #24396.
|
|
v2: Incorporate comments from Jamey on device name handling and extension
detection.
|
|
|
|
Remove bo pin for surface buffer access, and remove access
attempt for possible unmapped framebuffer. Using xv buffer
pointer to pass current xvmc surface bo handler, which is
assigned to src image bo and handle that the same way as in Xv.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
[anholt: Fixed up for conflict against the XV rework. Not tested, because
both mplayer and xine segfault with XVMC currently.]
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
While copying and rotating the buffer, array access was out of bounds when
rotated to the right (RR_Rotate_270). My buffer handling changes probably
made this bug much more likely to actually result in a SIGSEGV.
I've checked the logs and the bug exists since rotation has been supported,
i.e. this looks like a candidate for cherry-picking for all supported
releases.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
Kill some unnecessary stuff. Small code changes, but no functional ones.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
This code didn't survive the global renaming of vars to saner names.
Fix it up.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
Mostly unused definitions and variables, but also some strange ums
debug code. Also kill some now obsolete comments.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
If DEBUG_FLUSH_CACHES is enabled then emit a MI_FLUSH after every
rendering operation. This is intended to 'fix' cases where we are
missing a required flush in the middle of a sequence of operations, such
as switching between 2D to 3D and render to sampler.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Make the following options available via xorg.conf:
Section "Driver"
Option "DebugFlushBatches" "1" # Flush the batch buffer after every
# single operation;
Option "DebugFlushCaches" "1" # Include a MI_FLUSH at the end of every
# batch buffer to force data to be
# flushed out of cache and into memory
# before the completion of the batch.
Option "DebugWait" "1" # Wait for the completion of every batch buffer
# before continuing, i.e. perform synchronous
# rendering.
EndSection
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Failure to do so causes xrandr to report incorrect property values.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
By dropping the frontbuffer from the crtc, the new frontbuffer
can be properly added to the crtc when the xserver is reset.
Signed-off-by: Albert Damen <albrt@gmx.net>
|
|
Noticed this on Fedora, where 1.7 server does gamma via the randr
codepaths however kms doesn't have this call which happens in the
non set_mode_major path.
probably should be backported to released drivers.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Fallout from the conversion; DRI2 compat path was broken.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
It was cooking up insane alignment values for buffers that new libdrm was
justifiably complaining about, but it turns out we don't need the alignment
values anywhere because the only case they're needed, they're computed
entirely by the kernel. Also, the XVMC code was passing a completely unused
flag in.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also, start settling on the cairo naming for things: source, mask, and dest.
|
|
|
|
This is the beginning of the campaign to remove some of the absurd use of
Hungarian in the driver. Not that I don't like Hungarian, but I don't need
to know that pI830 is a pPointer.
|
|
|
|
|
|
|
|
|
|
|
|
We've talked about doing this since the start of the project, putting it off
until "some convenient time". Just after removing a third of the driver seems
like a convenient time, when backporting's probably not happening much anyway.
|
|
At this point, the only remaining feature regressions should be the lack of
overlay support (about to land), and the need to update the XVMC code to work
in the presence of KMS.
Acked-by: Keith Packard <keithp@keithp.com> (in principle)
Acked-by: Carl Worth <cworth@cworth.org> (in principle)
|
|
The replacement code is now landed, and the rest of UMS is about to disappear.
|
|
This is replaced by intel_gpu_dump, and would no longer be used once UMS is
gone.
|
|
This does not restore the overlay on EnterVT/disable it on LeaveVT.
Does not look like this is necessary.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[anholt: Hacked in avoiding the actual kernel calls with
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
This is the last preparatory step for overlay support with drmmode.
Safe two (specially marked) function calls in the setup code, all
hw accessing code goes now through these three new functions with
the ums_overlay prefix.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
The basic idea is to only pin the buffer into the gtt when
the overlay hw is actually using it. This results in a few changes:
- Unify data copied/buffer handling with textured video. Now offsets
are always buffer relative and we just use drm_bo_map to access a
buffer.
- Implement double buffering using two bo's. This is necessary because
we can't pin the same buffer to the gtt and map it as normal memory.
- Kill XV_DOUBLE_BUFFER. With the above changes, overlay video is always
doubel buffered.
There is still the XvMC passthrough case, which makes the code slightly
ugly. Unfortunately we can't get at the bo behind this buffer.
Changes since the last review-round:
- Don't overallocate by a factor of 2.
- Prevent possible use-after-free issue.
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
This way all thes strange special cases make much more sense.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
The code looks like it's been bitrotting since being copied over
from the i810 driver. Furthermore painting rgb pixmaps with the overlay
engine is in these days of modern compositing X an absolute no-go. And
textured video doesn't support it neither, so its likely never ever
used by applications.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
- scrap unused variable overlay
- scrap an superflous if and attach the code to the preceeding else
- tiny layout fix.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
Also scrap the unecessary variable sync in I830PutImage and the
accompanying obfuscated logic.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
Just moves the code and passes back allocation failures.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
Just move the code and pass back allocation failures.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
Just moves the code.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
It's only used to remember that XvMC has ỲV12 as output. is_planar_fourcc
already takes care of that in all necessary cases.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
The idea for the hw double buffering support is to program two fixed
buffers and then only switch buffers in the OCMD register. But the driver
as-is always programs the new buffer address (in both register sets
when double buffered). Therefore we gain nothing by using this hw
capability. Scrap the software support for it.
When double buffered, we now allocate just a buffer of size 2*size and
switch between the two parts purely in software.
To make reviewing this easier, I'll shortly explain the differences of how
double-buffering (i.e. tear-free video) is achieved before and after this
change:
- When double buffer, allocate a buffer twice the size (unchanged).
- Depending upon the currently shown buffer-half, copy the new frame into
the other buffer-half. In the old code this is done by using the right
set of buffer offsets, either *Buf0Offset or *Buf1Offset. The new code
simply programs the offset for the right buffer-half into the single set
of offsets. The end-result is unchanged.
Now the big difference in hw-programming:
Old: Programm new buffer offset into both sets of _hw_ buffer offset
registers. Depending upon the current _sw_ buffer, select the _hw_ buffer
and program this into the OCMD register. This just complicates matters
unnecessarly.
New: Just always use the hw buffer 0.
And then it's again the same story in both old and new code:
- Execute an overlay flip (MI_OVERLAY_FLIP) to read in the contents of the
hw registers into the shadow hw registers (which are actually being used
by the overlay, not the ones we write stuff into). This is synchronized
with the respective crtc vblank by the hw.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
Reduced 3 copies of the same code to one.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
This function only programs the overlay and is never called for textured
video. Make this obvious.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
