glamor: Change SET_PIXMAP_FBO_CURRENT from macro to static inline

This is the last function-like macro in glamor_priv.h; change to
static inline like all of the other functions there.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
glamor: Add macro __glamor_large in glamor_largepixmap.c

For now, this simply fetches the large member of the pixmap private.
It will be changed to assert that the pixmap is large once bugs
related to that have been fixed.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
glamor: Don't abuse large_pixmap members for regular pixmaps

glamor_compute_clipped_regions_ext wants to treat small and large
pixmaps uniformly and did that by writing into the large pixmap
union member in small pixmaps to construct something that looks like a
one texture large pixmap.

Instead of doing that, simply allocate the necessary elements locally
on the stack and use them from there.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
glamor: Handle compositing from large to small pixmaps

glamor_composite_largepixmap_region is given the job of dealing with
compositing between a mixture of large and small pixmaps. However, it
was assuming that the destination pixmap was large and fetching
members of the large structure even for small pixmaps.

This manifested with assertion failures when compositing from a large
pixmap to a small pixmap.

Fixed by using the pixmap size for the destination block size for
small pixmaps.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
glamor: Check large pixmap users in glamor_largepixmap.c

This enables the assertion that all users of the large pixmap member
are restricted to pixmaps which are actually large.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
glamor: Remove shader-based trapezoid implementation. Fixes Bug 76213.

I can't find any performance benefit to using the GL path and the code
renders this trapezoid incorrectly:

  		                 top: FIXED   29.50
		              bottom: FIXED   30.00
		            left top: POINT    0.00,   29.50
		         left bottom: POINT    0.00,   30.50
		           right top: POINT -127.50,   29.50
		        right bottom: POINT   52.50,   30.00

This should render a solid line from 0,30 to 52,30 but draws nothing.

The code also uses an area computation for trapezoid coverage which
does not conform to the Render specification which requires a specific
point sampling technique.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
xserver: Move 'pragma GCC diagnostic' outside functions

$ gcc --version
gcc (Gentoo 4.4.3-r2 p1.2) 4.4.3

/jhbuild/checkout/xorg/xserver/os/log.c: In function ‘LogInit’:
/jhbuild/checkout/xorg/xserver/os/log.c:199: error: #pragma GCC diagnostic not allowed inside functions
/jhbuild/checkout/xorg/xserver/os/log.c:201: warning: format not a string literal, argument types not checked
/jhbuild/checkout/xorg/xserver/os/log.c:212: error: #pragma GCC diagnostic not allowed inside functions
/jhbuild/checkout/xorg/xserver/os/log.c:214: warning: format not a string literal, argument types not checked

etc.

Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>