| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This is strictly the application of the script 'x-indent-all.sh'
from util/modular. Compared to the patch that Daniel posted in
January, I've added a few indent flags:
-bap
-psl
-T PrivatePtr
-T pmWait
-T _XFUNCPROTOBEGIN
-T _XFUNCPROTOEND
-T _X_EXPORT
The typedefs were needed to make the output of sdksyms.sh match the
previous output, otherwise, the code is formatted badly enough that
sdksyms.sh generates incorrect output.
The generated code was compared with the previous version and found to
be essentially identical -- "assert" line numbers and BUILD_TIME were
the only differences found.
The comparison was done with this script:
dir1=$1
dir2=$2
for dir in $dir1 $dir2; do
(cd $dir && find . -name '*.o' | while read file; do
dir=`dirname $file`
base=`basename $file .o`
dump=$dir/$base.dump
objdump -d $file > $dump
done)
done
find $dir1 -name '*.dump' | while read dump; do
otherdump=`echo $dump | sed "s;$dir1;$dir2;"`
diff -u $dump $otherdump
done
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
For fbAdd{Traps,Triangles}() and fbRasterizeTrapezoid() this is just a
matter of adding the image offsets to the trap offsets.
For fbShapes, the story is more complicated:
The recently added pixman API did not allow offsetting
trapezoids. Instead, it would use x_dst and y_dst in such a way that
the effect was to only offset the source image.
In pixman 0.21.8, this API has changed such that all the traps are
conceptually rendered to an infinitely big image, and the source and
destination coordinates are then aligned with (0, 0) of that
image. This means offsetting dst_x and dst_y will now offset the
entire drawing, which is similar to how other composite functions
work.
This patch then changes fbComposite{Triangles,Traps} such that the
source image is aligned with the shapes, and the destination
coordinates offset according to drawable->{x, y}.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Soren Sandmann <ssp@redhat.com>
|
|
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Soren Sandmann <ssp@redhat.com>
|
|
These calls no longer go through the CompositePicture() hook, so
damage was no longer generated for them. This patch simply damages the
entire destination clip region.
It would be possible to generate tighter damage for certain operators
such as Over and Add, where blank source pixels have no effect on the
destination, but given that virtually all trapezoid rendering takes
place on pixmaps, it's unlikely that anybody would actually benefit
from this optimization, and the miTrapezoidBounds function did
sometimes show up on profiles, probably because it does several
divisions per trapezoid.
V2: Call DamageRegionProcessPending() - pointed out by Michel Dänzer.
V3: Call DamageRegionProcessPending() *after* rendering -
pointed out by Maarten Maathuis
Reviewed-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Søren Sandmann <ssp@redhat.com>
|
|
This allows the remaining triangle-to-trap conversion code to be
deleted.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Søren Sandmann <ssp@redhat.com>
|
|
The fb version simply calls the new pixman_composite_triangles(). This
allows us to get rid of miCreateAlphaPicture().
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Søren Sandmann <ssp@redhat.com>
|
|
The main consumer of trapezoids, cairo, is using the Trapezoids
request, which is currently implemented in the miTrapezoids()
function. That function splits the request into smaller bits and calls
lower level functions such as AddTrap.
By moving the implementation of the whole request into fb, we can
instead call pixman_composite_trapezoids() to do the whole request in
one step.
There are no callers of miTrapezoids in any of the open source
drivers, although exa and uxa have their own copies of the function.
Reviewed-by: Adam Jackson <ajax@redhat.com>
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 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>
|
|
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>
|
|
This reverts commit e9aa61e9f0d663d5b34a397b943b4d1df44e873d.
Conflicts:
fb/fbpict.c
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).
|
|
Save in a few special cases, _X_EXPORT should not be used in C source
files. Instead, it should be used in headers, and the proper C source
include that header. Some special cases are symbols that need to be
shared between modules, but not expected to be used by external drivers,
and symbols that are accessible via LoaderSymbol/dlopen.
This patch also adds conditionally some new sdk header files, depending
on extensions enabled. These files were added to match pattern for
other extensions/modules, that is, have the headers "deciding" symbol
visibility in the sdk. These headers are:
o Xext/panoramiXsrv.h, Xext/panoramiX.h
o fbpict.h (unconditionally)
o vidmodeproc.h
o mioverlay.h (unconditionally, used only by xaa)
o xfixes.h (unconditionally, symbols required by dri2)
LoaderSymbol and similar functions now don't have different prototypes,
in loaderProcs.h and xf86Module.h, so that both headers can be included,
without the need of defining IN_LOADER.
xf86NewInputDevice() device prototype readded to xf86Xinput.h, but
not exported (and with a comment about it).
|
|
This is the biggest "visibility" patch. Instead of doing a "export"
symbol on demand, export everything in the sdk, so that if some module
fails due to an unresolved symbol, it is because it is using a symbol
not in the sdk.
Most exported symbols shouldn't really be made visible, neither
advertised in the sdk, as they are only used by a single shared object.
Symbols in the sdk (or referenced in sdk macros), but not defined
anywhere include:
XkbBuildCoreState()
XkbInitialMap
XkbXIUnsupported
XkbCheckActionVMods()
XkbSendCompatNotify()
XkbDDXFakePointerButton()
XkbDDXApplyConfig()
_XkbStrCaseCmp()
_XkbErrMessages[]
_XkbErrCode
_XkbErrLocation
_XkbErrData
XkbAccessXDetailText()
XkbNKNDetailMaskText()
XkbLookupGroupAndLevel()
XkbInitAtoms()
XkbGetOrderedDrawables()
XkbFreeOrderedDrawables()
XkbConvertXkbComponents()
XkbWriteXKBSemantics()
XkbWriteXKBLayout()
XkbWriteXKBKeymap()
XkbWriteXKBFile()
XkbWriteCFile()
XkbWriteXKMFile()
XkbWriteToServer()
XkbMergeFile()
XkmFindTOCEntry()
XkmReadFileSection()
XkmReadFileSectionName()
InitExtInput()
xf86CheckButton()
xf86SwitchCoreDevice()
RamDacSetGamma()
RamDacRestoreDACValues()
xf86Bpp
xf86ConfigPix24
xf86MouseCflags[]
xf86SupportedMouseTypes[]
xf86NumMouseTypes
xf86ChangeBusIndex()
xf86EntityEnter()
xf86EntityLeave()
xf86WrapperInit()
xf86RingBell()
xf86findOptionBoolean()
xf86debugListOptions()
LoadSubModuleLocal()
LoaderSymbolLocal()
getInt10Rec()
xf86CurrentScreen
xf86ReallocatePciResources()
xf86NewSerialNumber()
xf86RandRSetInitialMode()
fbCompositeSolidMask_nx1xn
fbCompositeSolidMask_nx8888x0565C
fbCompositeSolidMask_nx8888x8888C
fbCompositeSolidMask_nx8x0565
fbCompositeSolidMask_nx8x0888
fbCompositeSolidMask_nx8x8888
fbCompositeSrc_0565x0565
fbCompositeSrc_8888x0565
fbCompositeSrc_8888x0888
fbCompositeSrc_8888x8888
fbCompositeSrcAdd_1000x1000
fbCompositeSrcAdd_8000x8000
fbCompositeSrcAdd_8888x8888
fbGeneration
fbIn
fbOver
fbOver24
fbOverlayGeneration
fbRasterizeEdges
fbRestoreAreas
fbSaveAreas
composeFunctions
VBEBuildVbeModeList()
VBECalcVbeModeIndex()
TIramdac3030CalculateMNPForClock()
shadowBufPtr
shadowFindBuf()
miRRGetScreenInfo()
RRSetScreenConfig()
RRModePruneUnused()
PixmanImageFromPicture()
extern int miPointerGetMotionEvents()
miClipPicture()
miRasterizeTriangle()
fbPush1toN()
fbInitializeBackingStore()
ddxBeforeReset()
SetupSprite()
InitSprite()
DGADeliverEvent()
SPECIAL CASES
o defined as _X_INTERNAL
xf86NewInputDevice()
o defined as static
fbGCPrivateKey
fbOverlayScreenPrivateKey
fbScreenPrivateKey
fbWinPrivateKey
o defined in libXfont.so, but declared in xorg/dixfont.h
GetGlyphs()
QueryGlyphExtents()
QueryTextExtents()
ParseGlyphCachingMode()
InitGlyphCaching()
SetGlyphCachingMode()
|
|
Don't call fbFinishWrap until the pixman_image_t that stores the pointer is
actually freed. This prevents corruption or crashes caused by accessing a
wrapped pointer after the wrapping is torn down.
|
|
|
|
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
|
|
- Delete fbedge.c and fbedgeimp.h
- Use pixman_rasterize_edges() in fbtrap.c
|
|
Problem reported by Derek Abdine of rapid7.com. Thanks.
|
|
Create fbPrepareAccess macros to call into the driver to set up the
wfbReadMemory and wfbWriteWemory pointers. Call these from fbGetDrawable and
fbGetStipDrawable.
Add the READ and WRITE macros, which expand to simple memory accesses for fb,
and calls through the function pointers for wfb.
Add fbFinishAccess macro to give the driver an opportunity to clean up. Add
calls to this in the appropriate places.
|
|
Add XSERV_t, TRANS_SERVER, TRANS_REOPEN to quash warnings.
Add #include <dix-config.h> or <xorg-config.h>, as appropriate, to all
source files in the xserver/xorg tree, predicated on defines of
HAVE_{DIX,XORG}_CONFIG_H. Change all Xfont includes to
<X11/fonts/foo.h>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
