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>
Tiling on gen 2/3 hardware is only supported for pitches up to 8192
bytes, so above this limit the surface will be untiled and we will no
longer have to comply with the power-of-two pitch alignment. So
disabling tiling for these too wide surface should ~halve the memory
requirement for the full surface.
Also the absolute limit for the 2D blitter is 32,768 bytes. The
documentation says "up to 32,768 bytes" and my PineView box was
malfunction with a surface stride of 32,768 so set the limit to be
32,767.
References:
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>
Oops, I spent more time discussing these flushing bugs than I spent
paying attention to what I was actually doing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is a situation that should not be possible, need_mi_flush being
true but the list of pending flush pixmaps being clear. However, an
earlier bug in doing just that revealed this minor bug. So for
correctness, be careful not to clear need_mi_flush without emitting a
MI_FLUSH.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The key difference between i965 and earlier, is that the surfaces passed
to the samplers through an indirect table and so the batch and render
target was not being marked dirty by the relocation (since the
relocation only happens within prepare_composite() which may have been
in another batch.) Simply call intel_pixmap_mark_dirty() when binding
the sampler table into the batch to ensure that the dirty is tracked
appropriately.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>