Chris Wilson likes to sprinkle these all over, but in this
case it's just misleading. libdrm already does this for us.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The kernel overlay code does asynchronous overlay flips. So keep
onto two old buffers, for otherwise the rendering of the next
frame might overwrite the contents of the currently still displaying
one. With ~25fps videos and ~50 Hz screens that's rather unlikely,
still, fix it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Per-target compilation flags (libIntelXvMC_la_CFLAGS) are required
when multiple targets which require different compiler flags,
are build in the same makefile.
Automake issues a command with -c and -o flags which not all compilers
support. The object fles are prefixed with libIntelXvMC_la.
The macro AM_PROG_CC_C_O must then be used to provide this feature
on compilers that do not have it. If not, a warning is issued at make time.
This macros checks for compiler support and if missing, uses a "compile"
script it generates in the package root directory.
Currently the driver uses per-target flags but the macro is missing.
Rather than adding the macro, this patch stops using per-target flags
by using the AM_CFLAGS variable for all targets in the makefile, as
there is only one.
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Autoconf says:
"This macro is obsolescent, as current systems have conforming
header files. New programs need not use this macro".
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
XORG_STRICT_OPTION from XORG_DEFAULT_OPTIONS calls
AC_PROG_C_C99. This sets gcc with -std=gnu99.
If AC_PROG_CC macro is called afterwards, it resets CC to gcc.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Unrelated to the previous patches, the new value simply reflects
the reality that the minimum level for autoconf to configure
all x.org modules is 2.60 dated June 2006.
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.60.tar.gz
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Order is important. And ensure that the scratch GC is performing clip by
children.
Fixes:
Bug 29213 - video artifacts if used dualscreen mode
https://bugs.freedesktop.org/show_bug.cgi?id=29213
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After passing the new buffer to the kernel, the old buffer is unpinned
and becomes available for re-use. So keep hold of the old buffer and
swap after a PutImage. This greatly reduces the amount of CPU time
consumed by the kernel on behalf of the video overlay -- by only
allocating two buffers for an entire sequence, we avoid clflushing and
page allocation on every frame.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to cleanup all CRTCs and outputs on shutdown, we need to keep a
list of the individual structures and iterate over that list on
shutdown.
Also, the output and crtcs are configured just once and not for each
screen generation so move the shutdown to the termination and not on
CloseScreen. Oops.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we use the static DummyEncoding and may attempt to modify it for each
adaptor (on each device), we should use copies instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This avoids a memory leak on server reset.
Signed-off-by: Keith Packard <keithp@keithp.com>
[ickle: Added comments from Keith that explain the necessity of
destroying the pixmap ourselves and why chaining up in this instance is
not the correct approach.]
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
The dri code is much more careful in ensuring that the scan lines that
is waits for are valid. Copy this code to video, with a bit of work this
can be refactored, and perhaps even teach dri how to handle rotated
front buffers.
References:
Bug 28964 - [i965gm] GPU infinite MI_WAIT_FOR_EVENT while watching video
in Totem
https://bugs.freedesktop.org/show_bug.cgi?id=28964
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
planemask is an unsigned long initialised to ~0, on 64-bit this is not equal
to an (unsigned int)-1.
Use the macro provided to do this.
Signed-off-by: Dave Airlie <airlied@redhat.com>
If we reject the front buffer because it has too large a stride, repeat
the allocation using untiled for the cases where we can utilize laxer
hardware restrictions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Avoid a potential use-after-free of the copied mode string by reusing
the converted kernel mode on resize.
==19897== Invalid read of size 8
==19897== at 0x661C330: ??? (strcpy.S:1308)
==19897== by 0x8618AE7: drmmode_set_mode_major (drmmode_display.c:293)
==19897== by 0x8618E6F: drmmode_xf86crtc_resize (drmmode_display.c:1299)
==19897== by 0x529A77: xf86RandR12ScreenSetSize (xf86RandR12.c:708)
==19897== by 0x4BD528: ProcRRSetScreenSize (rrscreen.c:301)
==19897== by 0x42B820: Dispatch (dispatch.c:432)
==19897== by 0x4254C9: main (main.c:289)
==19897== Address 0x72e91e0 is 0 bytes inside a block of size 9 free'd
==19897== at 0x4C23DBC: free (vg_replace_malloc.c:325)
==19897== by 0x48424F: xf86DeleteMode (xf86Mode.c:1921)
==19897== by 0x4942B7: xf86ProbeOutputModes (xf86Crtc.c:1572)
==19897== by 0x5290BB: xf86RandR12GetInfo12 (xf86RandR12.c:1551)
==19897== by 0x5313AE: RRGetInfo (rrinfo.c:202)
==19897== by 0x4BCCAA: rrGetScreenResources (rrscreen.c:337)
==19897== by 0x42B820: Dispatch (dispatch.c:432)
==19897== by 0x4254C9: main (main.c:289)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Unwind the array of Pixmaps already allocated and report failure for the
old dri GetBuffers() path.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After splitting out the i810 driver into its own legacy directory, we
can identify the common routines not as i830 but as intel. This
clarifies the code which *is* i830 specific.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The driver is still built but is no longer under active development so
move it and supporting files to a new directory.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the source is outside the drawable, then CopyArea will fail to
initialise the source correctly. The simplest fix in this case is to
fallback to pixman to generate the source texture.
Fixes:
Bug 28497 - Graphics corruption after opening a specific website
https://bugs.freedesktop.org/show_bug.cgi?id=28497
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>