This should not have been there, and I'm honestly not sure why
I even had it on my branch...
Sorry for the noise. I'm going to go hide in a corner now.
This reverts commit 4975887a30.
The only user of the geometry coordinates is the software sprite code,
which uses them to remove the pointer whenever the window beneath is
being used as a source. However, using Window pictures as a source is
extremely rare (let alone *partial* windows), so there is no harm done
in just validating all of the drawable.
Additionally, the miSourceValidate() function was buggy in at least
three respects:
(a) It added drawable->{x,y} before calling down, which is wrong since
the misprite code already adds them in its check. (Alternatively,
the misprite code is wrong, but there are actual users who would
notice if that code was broken).
(b) It didn't account for the width of the interpolation filter, so if
the Picture had a bilinear or convolution filter, the edges
surrounding the source area would not be validated.
(c) It didn't validate alpha maps.
Finally, computing the bounding box of the transform on every
composite request was a real performance issue in pixman, so
presumably it could be one here as well.
This patch changes miSourceValidate() to simply validate all of the
underlying drawable.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Soren Sandmann <ssp@redhat.com>
(cherry picked from commit 57b35adaed)
The memcpy fast path implicitly assumes that the copy walks
left-to-right. That's not something memcpy guarantees, and newer glibc
on some processors will indeed break that assumption. Since we walk a
line at a time, check the source and destination against the width of
the blit to determine whether we can be sloppy enough to allow memcpy.
(Having done this, we can remove the check for !reverse as well.)
On an Intel Core i7-2630QM with an NVIDIA GeForce GTX 460M running in
NoAccel, the broken code and various fixes for -copywinwin{10,100,500}
gives (edited to fit in 80 columns):
1: Disable the fastpath entirely
2: Replace memcpy with memmove
3: This fix
4: The code before this fix
1 2 3 4 Operation
------ --------------- --------------- --------------- ------------
258000 269000 ( 1.04) 544000 ( 2.11) 552000 ( 2.14) Copy 10x10
21300 23000 ( 1.08) 43700 ( 2.05) 47100 ( 2.21) Copy 100x100
960 962 ( 1.00) 1990 ( 2.09) 1990 ( 2.07) Copy 500x500
So it's a modest performance hit, but correctness demands it, and it's
probably worth keeping the 2x speedup from having the fast path in the
first place.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit e32cc0b4c8)
Clears many Sun compiler warnings:
"fbbltone.c", line 491: warning: integer overflow detected: op "<<"
"fbbltone.c", line 491: warning: integer overflow detected: op "<<"
"fbbltone.c", line 491: warning: integer overflow detected: op "<<"
"fbbltone.c", line 491: warning: initializer will be sign-extended: -16777216
"fbbltone.c", line 491: warning: integer overflow detected: op "<<"
"fbbltone.c", line 491: warning: initializer will be sign-extended: -1
"fbbltone.c", line 495: warning: integer overflow detected: op "<<"
"fbbltone.c", line 495: warning: integer overflow detected: op "<<"
"fbbltone.c", line 495: warning: integer overflow detected: op "<<"
"fbbltone.c", line 495: warning: initializer will be sign-extended: -256
"fbbltone.c", line 495: warning: integer overflow detected: op "<<"
"fbbltone.c", line 495: warning: initializer will be sign-extended: -1
"fbbltone.c", line 499: warning: integer overflow detected: op "<<"
"fbbltone.c", line 499: warning: integer overflow detected: op "<<"
"fbbltone.c", line 499: warning: integer overflow detected: op "<<"
"fbbltone.c", line 499: warning: initializer will be sign-extended: -65536
"fbbltone.c", line 499: warning: integer overflow detected: op "<<"
"fbbltone.c", line 499: warning: initializer will be sign-extended: -1
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 1b2d17748f)
Free the pointers inside miInitVisuals, so the callers of this function
(fboverlay.c and fbscreen.c) don't need to worry with deallocation in the case
of failure.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Nicolas Peninguy <nico@lostgeeks.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This is obsolete since a240c039c4.
Updated fb.h to mention that the functions come from fbcmap_mi.c now.
Dropped fbcmap.c from the makefile.
Signed-off-by: Jesse Adkins <jesserayadkins@gmail.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
All of these definitions were unused since compositing moved to pixman.
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Signed-off-by: Søren Sandmann <ssp@redhat.com>
This function was an unused and trivial wrapper around fbComposite().
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Signed-off-by: Søren Sandmann <ssp@redhat.com>
The functions in these files have not been used since trap
rasterization was moved to pixman. They survived until now to preserve
the server abi.
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Signed-off-by: Søren Sandmann <ssp@redhat.com>
This function has not been used since most of the compositing was
moved to pixman. The only reason it has survived until now is that it
was part of the server ABI.
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Signed-off-by: Søren Sandmann <ssp@redhat.com>
The fb functions they try to rename were deleted in 2007 by
commit ae7f71a8b3
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Tested-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When a GC is allocated, it is zeroed, including all storage requested
with dixRegisterPrivateKey. So CreateGC hooks don't need to initialize
anything to zero.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
A window with either dimension > 32767 can be positioned such that
coordinates > 32767 are visible on the screen. Attempts to draw to
those pixels will generate coordinates wrapped around to negative
values.
The optimized clipping macro, 'isClipped', in fbbits.h, computes
clipping in window space rather than screen space using int16 values,
and so it too has coordinates wrapped around to negative values and
hence ends up accepting the wrapped drawing coordinates.
Two possible fixes for this problem
1) Detect wrapped region coordinates and clip those to 32767.
2) Detect negative incoming coordinates and reject those
This patch takes the second approach as it is much shorter, simply
detecting when either X or Y incoming coordinate is negative, which
can never be 'within' any drawable.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Recursive alpha maps (where one picture's alpha map is set to a
picture with an external alpha map) would be all fine and dandy,
except for the case where the client constructs a loop. Detecting this
case when setting the alpha map values would be difficult as any time
an alpha map is set, the server would have to check for the looping
case.
Instead, a far simpler fix is to simply disallow recursive alpha maps
in the rendering code, the Render spec is ambiguous in this area and
allows us to to ignore the recursive case.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Helps with symbol resolution when building with -z defs
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
This patch was generated by the following Perl code:
perl -i -pe 's/([^_])return\s*\(\s*([^(]+?)\s*\)s*;(\s+(\n))?/$1return $2;$4/g;'
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
This patch only changes the API, not the implementation of the
devPrivates infrastructure. This will permit a new devPrivates
implementation to be layed into the server without requiring
simultaneous changes in every devPrivates user.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com>
This is a combination of a huge mechanical patch and a few small
fixups required to finish the job. They were reviewed separately, but
because the server does not build without both pieces, I've merged
them together at this time.
The mechanical changes were performed by running the included
'fix-region' script over the whole tree:
$ git ls-files | grep -v '^fix-' | xargs ./fix-region
And then, the white space errors in the resulting patch were fixed
using the provided fix-patch-whitespace script.
$ sh ./fix-patch-whitespace
Thanks to Jamey Sharp for the mighty fine sed-generating sed script.
The hand-done changes involve removing functions from dix/region.c
that duplicate inline functions in include/regionstr.h, along with
their declarations in regionstr.h, mi.h and mispans.h.
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This prepares the file to be moved from mi to dix. This patch
was done mechanically with the included scripts 'fix-miregion' run over
the entire X server and 'fix-miregion-private' run over
include/regionstr.h and mi/miregion.c.
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Many references to the WindowTable array already had the corresponding
screen pointer handy, which meant they usually looked like
"WindowTable[pScreen->myNum]". Adding a field to ScreenRec instead of
keeping this information in a parallel array simplifies those
expressions, and eliminates a MAXSCREENS-sized array.
Since dix uses this data, a screen private entry isn't appropriate.
xf86-video-dummy currently uses WindowTable, so it needs to be updated
to reflect this change.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com> (i686 GNU/Linux)
This doesn't change any behavior, but it isn't clear whether NullClient
is correct in all cases. As ajax says,
> For most of these changes, I think it's correct to use NullClient,
> since they are server-initiated changes and should not fail for (eg)
> xace reasons. ... At any rate, you're certainly not changing any
> semantics by leaving them all as NullClient, so this patch can't be
> more wrong than before.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
The only remaining X-functions used in server are XNF*, the rest is converted to
plain alloc/calloc/realloc/free/strdup.
X* functions are still exported from server and x* macros are still defined in
header file, so both ABI and API are not affected by this change.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Several DDXes allow each screen to have at most one (or in some cases,
exactly one) installed colormap. These all use the same pattern: Declare
a global-lifetime array of MAXSCREENS ColormapPtrs, and index it by
screen number. This patch converts most of those to use screen privates
instead.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Acked-by: Tiago Vignatti <tiago.vignatti@nokia.com>
This patch was created with:
git ls-files '*.[ch]' | while read f; do unifdef -B -DRENDER -o $f $f; done
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Oliver McFadden <oliver.mcfadden@nokia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
*xoff and *yoff were uninitialized for source-only pictures.x
Signed-off-by: Pierre-Loup A. Griffais <pgriffais@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Windows (or even pixmaps, in some cases) may not sit at the origin of
the containing pixmap, so any coordinates relative to the drawable
must be adjusted. For destinations and untransformed sources, the
operation coordinates are adjusted. For transformed sources, the
transform matrix is adjusted.
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Soeren Sandmann <sandmann@daimi.au.dk>
These two sub-macros each perform half of the original macro work and
the old macro is now implemented in terms of the new ones. This makes
way for new code which wants to know the underlying pixmap for a
window instead of just getting a pointer to the bits.
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Soeren Sandmann <sandmann@daimi.au.dk>
The new clipping rules:
- client clips happen after transformation
- pixels unavailable due to the hierarchy are undefined
The first one is implemented in pixman; the second one is realized by
making a copy of window sources (to prevent out-of-bounds access).
