Daniel Stone writes:
>> To make X -configure work properly, the output of fixup_video_driver_list()
>> should be in order of preference. Otherwise, the config file may use
>> the incorrect driver for some devices.
>>
>> In particular, the drivers that work for all (or many) devices need to be
>>
driver works for many devices,
it needs to be considered a fallback driver.
Signed-off-by: Søren Sandmann
---
hw/xfree86/common/xf86Config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index 2adef44..481674d
From: Søren Sandmann
To make X -configure work properly, the output of fixup_video_driver_list()
should be in order of preference. Otherwise, the config file may use
the incorrect driver for some devices.
In particular, the drivers that work for all (or many) devices need to be
last in the list
Markus Trippelsdorf writes:
> There is an interesting discussion on the FreeType mailing-list about
> the necessity to use linear blending for glyphs:
> http://thread.gmane.org/gmane.comp.fonts.freetype.devel/9105
> http://thread.gmane.org/gmane.comp.fonts.freetype.devel/9117
>
> Currently Linux
git://people.freedesktop.org/~sandmann/xserver for-keithp
Søren Sandmann Pedersen (3):
xf86AddBusDeviceToConfigure(): Store device in DevToConfig[i].pVideo
ephyr: hostx_screen_init(): Fix bits_per_pixel and bytes_per_line
ephyr: Ensure stride of private framebuffer is multiple of 4
hw/kdrive/
Michele Baldessari writes:
> this fixes it for me for both the normal case and the resizeable case.
> I noticed that if I launch DISPLAY=:1 xclock on Xephyr -screen 320x200x8 :1
> and then
> kill xclock, I get the following backtrace:
> ephyrScreenInitialize (screen=0x823d50) at ephyr.c:124
> 12
From: Søren Sandmann Pedersen
The fb layer of X can't deal with strides that are not a multiple of
4, so when Xephyr allocates its own framebuffer it should make sure to
align it.
This fixes crashes and rendering corruption when Xephyr runs in a
depth that is different from the host X s
From: Søren Sandmann Pedersen
When the depth of the Xephyr server matches that of the host X server,
Xephyr simply uses the buffer associated with the XImage as its
framebuffer. In this case, it is correct to get the bits_per_pixel and
bytes_per_line values returned from hostx_screen_init() from
Søren Sandmann writes:
> From: Søren Sandmann Pedersen
Please ignore this old patch, which was sent by mistake
Soren
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mail
From: Søren Sandmann Pedersen
After fc3ab84d the pVideo field in DevToConfig[i] is no longer
initialized, so it's always NULL. This causes the duplicate finding
algorithm in the beginning of the function to not work anymore as it
is based on this field.
The symptom of this bug is t
From: Søren Sandmann Pedersen
This new API allows glyphs to be cached in a data structure in pixman,
and entire glyph strings to be composited in one go.
Also bump pixman dependency to 0.27.2.
Results from the cairo peformance test suite running against Xvfb with
a screen size of 1680x1050
From: Søren Sandmann Pedersen
This option is mentioned in the man page, but not in the help text
---
Apologies if this shows up twice on the list.
xauth.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/xauth.c b/xauth.c
index 13f6ace..4db47fb 100644
--- a/xauth.c
ndercheck)
> for the "color expected" from the background.
>
> Attaching the patch and the snapshots for reference.
Reviewed-by: Søren Sandmann
See also
http://lists.freedesktop.org/archives/pixman/2013-April/002755.html
for some rat
Aaron Plattner writes:
> Renaming this function was missed in commit
> 9cbcb5bd6a5360a128d15b77a02d8d3351f74366, so both libfb.so and libwfb.so
> define
> functions named fbDestroyGlyphCache.
Reviewed-by: Søren Sandmann
___
xorg-devel
Peter Hutterer writes:
> fbpict.c: In function 'fbGlyphs':
> fbpict.c:188:6: warning: declaration of 'x' shadows a previous local
> [-Wshadow]
> fbpict.c:111:9: warning: shadowed declaration is here [-Wshadow]
> fbpict.c:188:9: warning: declaration of 'y' shadows a previous local
> [-Wshadow]
> f
Peter Hutterer writes:
> Signed-off-by: Peter Hutterer
Reviewed-by: Søren Sandmann >
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Peter Hutterer writes:
> The double_to_f1616() functions do the same thing, and they're tested.
>
> Signed-off-by: Peter Hutterer
> ---
> Turns out we already have these functions and the macro was just a leftover
> from earlier, happier times.
Is there any reason to not just use the pixman_dou
The following changes since commit a69429a17bf4630f6e26f61630a1c2b287202627:
Fix 'make distcheck' for hw/xwin (2012-10-11 12:54:12 +0100)
are available in the git repository at:
git+ssh://sandm...@people.freedesktop.org/~sandmann/xserver for-keithp
Søren Sandmann Pedersen (1):
1034,7 +1034,7 @@ KdGetOptions(InputOption **options, char *string)
>
> if (strchr(string, '=')) {
> tam_key = (strchr(string, '=') - string);
> -key = strndup(string, tam_key + 1);
> +key = strndup(string, tam_key);
> if
From: Søren Sandmann Pedersen
This new API allows glyphs to be cached in a data structure in pixman,
and entire glyph strings to be composited in one go.
Also bump pixman dependency to 0.27.2.
Results from the cairo peformance test suite running against Xvfb with
a screen size of 1680x1050
Keith Packard writes:
> Søren Sandmann writes:
>
>> Søren Sandmann Pedersen (1):
>> Use new pixman_glyph_cache_t API that will be in pixman 0.28.0
>
> The code looks fine to me; I wonder if the glyphCache should be freed at
> server regen time though, mostly
ict(), as is the case for alphamaps.
>
> Reviewed-by: Aaron Plattner
> Signed-off-by: Arcady Goldmints-Orlov
Reviewed-by: Søren Sandmann
Soren
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Inf
Hi,
The following unreviewed change since commit
0b02150c27e98f996e10d7489f9f67a30e4e3497:
dix: fix scale_to_desktop for edge ABS events (2012-09-24 11:12:04 -0700)
is available in the git repository at:
git://people.freedesktop.org/~sandmann/xserver glyph2
Søren Sandmann Pedersen (1
From: Søren Sandmann Pedersen
This new API allows glyphs to be cached in a data structure in pixman,
and entire glyph strings to be composited in one go.
Also bump pixman dependency to 0.27.2.
Results from the cairo peformance test suite running against Xvfb with
a screen size of 1680x1050
Aaron Plattner writes:
> I ran some cairo-perf-trace numbers on Xorg with an accelerated driver.
>
> xorg-server-1.13.0, glyph cache disabled:
> [ # ] backend test min(s) median(s) stddev. count
> [ 0] xlibfirefox-particles 40.857 40.865 0.02%
"Pierre-Loup A. Griffais" writes:
> On 09/11/2012 10:43 AM, Søren Sandmann wrote:
>> "Pierre-Loup A. Griffais" writes:
>>
>>> I'm not very familiar with bicubic interpolation, but couldn't it be
>>> achieved using the 'co
"Pierre-Loup A. Griffais" writes:
> I'm not very familiar with bicubic interpolation, but couldn't it be
> achieved using the 'convolution' filter with the adequate kernel?
> (possibly in several passes at different scales). AFAIK 'convolution'
> is always provided and often accelerated.
The con
This new API allows glyphs to be cached in a data structure in pixman,
and entire glyph strings to be composited in one go.
Also bump pixman dependency to 0.27.2.
Results from the cairo peformance test suite running against Xvfb with
a screen size of 1680x1050@32bpp:
Speedups
xlib
Now that 1.13 is out and there has been a pixman release with the new
API, let me try this again.
This patch speeds up glyph rendering by caching glyphs in a pixman
data structure. There are numbers in the commit message.
It is important to note that this patch implies a small semantic
change to
Knut Petersen writes:
> Søren, the bad commit was supposed to fix a gcc -O0 compile problem, but it
> breaks
> gcc -O0 compilation here. Reverting f9c91ee2 fixes the problem for me.
Thanks for the bug report. Can you please try the following patch and
let me know if it fixes the problem?
Sore
From: Søren Sandmann Pedersen
When not optimizing, write _mm_shuffle_pi16() as a statement
expression with inline assembly. That way we avoid
__builtin_ia32_pshufw(), which is only available when compiling with
-msse, while still allowing the non-optimizing gcc to understand that
the second
From: Søren Sandmann Pedersen
This new API allows glyphs to be cached in a data structure in pixman,
and entire glyph strings to be composited in one go.
Results from the cairo peformance test suite running against Xvfb with
a screen size of 1680x1050@32bpp:
Speedups
xlib
Søren Sandmann writes:
> The following patch ports fb over to use a proposed new glyph cache
> API for pixman 0.28.0. That API is described in this thread:
There is a new version of the glyph API series here:
http://lists.freedesktop.org/archives/pixman/2012-June/002024.html
The X
Keith Packard writes:
> Are you duplicating the glyph image data in pixman? Or just saving the
> pointer?
I'm duplicating the glyph image data. It's similar in concept to how
hardware drivers duplicate the image data in textures.
It could perhaps be interesting to share the data between X and
Alan Coopersmith writes:
> I note the pixman patches use a custom hash function instead of the standard
> SHA1 hash the X server currently uses (and currently tries to find an
> accelerated version of) - any idea if this factors into the performance at
> all?
Well, the hashes serve two differen
Keith Packard writes:
> Søren Sandmann writes:
>
>> I verified that the cairo test suite has the number of failures as
>> without the patch.
>
> Any performance comparisons?
Yeah, in the commit message for the patch itself.
Soren
__
From: Søren Sandmann Pedersen
This new API allows glyphs to be cached in a data structure in pixman,
and entire glyph strings to be composited in one go.
Results from the cairo peformance test suite running against Xvfb with
a screen size of 1680x1050@32bpp:
Speedups
xlib
The following patch ports fb over to use a proposed new glyph cache
API for pixman 0.28.0. That API is described in this thread:
http://lists.freedesktop.org/archives/pixman/2012-May/002009.html
and is available as a git repository here:
http://cgit.freedesktop.org/~sandmann/pixman/log/?h=
Keith Packard writes:
> Yeah, if you come up with a script that fixes things, we can apply
> that. Alternatively, just post cleanup patches and we'll merge them in
> and hope that we don't impact cross-version patches too much.
>
> Fixing 20 years of format neglect isn't going to be completely pa
>From 259d46168c0f28e861ebb6cf1c7abe2605a55030 Mon Sep 17 00:00:00 2001
Cairo 1.10 will sometimes generate trapezoids like this, so we can't
consider them invalid. Fixes bug 45009, reported by Michael Biebl.
This reverts commit 2437ae80e5066dec9fe52f56b016bf136d7cea06.
---
pixman/pixman.h
Hi,
The following patch reverts 259d46168c0f2, which was a change that made
trapezoids like this one invalid:
-- top
\
\/
left right
\
Michel Dänzer writes:
> On Die, 2011-10-04 at 15:52 -0700, Aaron Plattner wrote:
>> This caused a performance regression because previously, miTrapezoids
>> would render its mask image into a scratch pixmap and then perform the
>> final composite using a possibly-accelerated RENDER Composite c
zhigang gong writes:
>> I am not very familiar with either cairo/pixman, just know that it is
>> used in spice, and it has a GL backend. There is also clutter, and some
>> other open source 2D GL rendering libraries (qt canvas is also interesting,
>> although I guess it's C++). How is glamor rela
From: Søren Sandmann Pedersen
Pixman used to have a workaround for a bug in old X servers, and this
function was used to disable that workaround in servers known to be
fixed.
In current versions of pixman, including the version the X server
depends on, the workaround doesn't exist anymor
From: Søren Sandmann Pedersen
Nothing uses them.
---
render/glyph.c | 45 +
render/mipict.c |2 --
render/mipict.h |8
render/picturestr.h |9 -
4 files changed, 1 insertions(+), 63 deletions(-)
diff --git
From: Søren Sandmann Pedersen
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
From: Søren Sandmann Pedersen
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
From: Søren Sandmann Pedersen
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
From: Søren Sandmann Pedersen
Previously, this function would do coordinate calculations in such a
way that (x_dst, y_dst) would only affect the alignment of the source
image, but not of the traps, which would always be considered to be in
absolute destination coordinates. This is unlike the
Hi,
I got no comments on these, and would like to make a pixman release
soon that includes the pixman patch. Once that happens, all trapezoid
rendering will be completely wrong unless the server patch is also
applied.
There is also the series starting here:
http://lists.x.org/archives/xorg
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
t
The following patches to pixman and X server respectively should fix
trapezoid rendering to windows. Before drawable offsets were ignored.
Fixing this uncovered that the pixman API I added was pretty broken
because it would always treat the trapezoid coordinates as if they
were in destination spac
Previously, this function would do coordinate calculations in such a
way that (x_dst, y_dst) would only affect the alignment of the source
image, but not of the traps, which would always be considered to be in
absolute destination coordinates. This is unlike the
pixman_image_composite() function wh
From: Søren Sandmann Pedersen
They are not used anymore.
Signed-off-by: Soren Sandmann
---
render/mipict.c | 84 ---
render/mipict.h | 10 --
2 files changed, 0 insertions(+), 94 deletions(-)
diff --git a/render/mipict.c b/render
From: Søren Sandmann Pedersen
It is not used anywhere else.
Signed-off-by: Soren Sandmann
---
fb/fbpict.c| 47 +-
fb/fbpict.h|7 ++
render/Makefile.am |1 -
render/mipict.c|2 +-
render/mipict.h|7 --
render/mirect.c| 185
From: Søren Sandmann Pedersen
Signed-off-by: Soren Sandmann
---
fb/fbtrap.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fb/fbtrap.c b/fb/fbtrap.c
index 612fae7..b5c5a61 100644
--- a/fb/fbtrap.c
+++ b/fb/fbtrap.c
@@ -111,6 +111,8 @@ fbShapes (CompositeShapesFunc
From: Søren Sandmann Pedersen
Signed-off-by: Soren Sandmann
---
render/picturestr.h | 18 --
1 files changed, 0 insertions(+), 18 deletions(-)
diff --git a/render/picturestr.h b/render/picturestr.h
index c536c38..7b7f911 100644
--- a/render/picturestr.h
+++ b/render
From: Søren Sandmann Pedersen
The fields class, stopRange, colorTable and colorTableSize are not
used by any current code.
Signed-off-by: Soren Sandmann
---
render/picture.c| 13 -
render/picturestr.h | 25 -
2 files changed, 0 insertions(+), 38
From: Søren Sandmann Pedersen
PictureGradientColor(), INTERPOLATE_PIXEL_256() and premultiply() are
not used by anything.
Signed-off-by: Soren Sandmann
---
render/picture.c| 45 -
render/picturestr.h |5 -
2 files changed, 0 insertions
From: Søren Sandmann Pedersen
In CompositeTriStrip() pScreen and ps are not used. In
CompositeTriFan(), pScreen is not used.
Signed-off-by: Soren Sandmann
---
render/picture.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/render/picture.c b/render/picture.c
index
From: Søren Sandmann Pedersen
The interface to RegionInit():
RegionInit (RegionPtr pReg, BoxPtr rect, int size);
is very confusing because it doesn't take a list of boxes, it takes
*one* box, but if that box is NULL, it initializes an empty region
with 'size' rectangles prea
From: Søren Sandmann Pedersen
These calls no longer go through the miComposite(), 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
From: Søren Sandmann Pedersen
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
From: Søren Sandmann Pedersen
These functions no longer go through the screen vtable, so remove
them and fix up the various wrappers.
Signed-off-by: Soren Sandmann
---
hw/dmx/dmx.h |2 -
hw/dmx/dmxpict.c | 87 --
hw/dmx
From: Søren Sandmann Pedersen
There is no need to virtualize this function that nobody cares about.
Signed-off-by: Soren Sandmann
---
render/mitri.c | 19 ---
render/picture.c | 22 ++
2 files changed, 18 insertions(+), 23 deletions(-)
diff --git a
From: Søren Sandmann Pedersen
There is no need to virtualize this function that nobody cares about.
Signed-off-by: Soren Sandmann
---
render/mitri.c | 21 -
render/picture.c | 23 +++
2 files changed, 19 insertions(+), 25 deletions(-)
diff --git
The following patches absorb the miTriFan() and miTriStrip() functions
into CompositeTriFan() and CompositeTriStrip() respectively, and then
delete the TriStrip and TriFan hooks from PictureScreen.
None of the open source drivers have ever used these hooks, so there
is no point maintaining them.
From: Søren Sandmann Pedersen
These functions no longer go through the screen vtable, so remove
them and fix up the various wrappers.
---
hw/dmx/dmx.h |2 -
hw/dmx/dmxpict.c | 87 --
hw/dmx/dmxpict.h | 10 --
miext/cw
From: Søren Sandmann Pedersen
There is no need to virtualize this function that nobody cares about.
---
render/mitri.c | 19 ---
render/picture.c | 22 ++
2 files changed, 18 insertions(+), 23 deletions(-)
diff --git a/render/mitri.c b/render/mitri.c
From: Søren Sandmann Pedersen
There is no need to virtualize this function that nobody cares about.
---
render/mitri.c | 21 -
render/picture.c | 23 +++
2 files changed, 19 insertions(+), 25 deletions(-)
diff --git a/render/mitri.c b/render
From: Søren Sandmann Pedersen
Nothing uses it.
Signed-off-by: Soren Sandmann
---
dix/region.c| 234 ---
include/regionstr.h | 10 --
2 files changed, 0 insertions(+), 244 deletions(-)
diff --git a/dix/region.c b/dix/region.c
index
From: Søren Sandmann Pedersen
This allows the remaining triangle-to-trap conversion code to be
deleted.
Signed-off-by: Søren Sandmann
---
fb/fbtrap.c | 91 ++-
1 files changed, 9 insertions(+), 82 deletions(-)
diff --git a/fb/fbtrap.c
From: Søren Sandmann Pedersen
The fb version simply calls the new pixman_composite_triangles(). This
allows us to get rid of miCreateAlphaPicture().
Signed-off-by: Søren Sandmann
---
fb/fbpict.c |1 +
fb/fbpict.h | 10 +
fb/fbtrap.c | 109
From: Søren Sandmann Pedersen
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
From: Søren Sandmann Pedersen
This allows some more code to be deleted from the X server. The
implementation consists of converting to trapezoids, and is shared
with pixman_composite_triangles().
---
pixman/pixman-trap.c | 61 -
pixman/pixman.h
From: Søren Sandmann Pedersen
When the source is opaque and the destination is alpha only, we can
avoid the temporary mask and just add the trapezoids directly.
---
pixman/pixman-trap.c | 133 -
1 files changed, 76 insertions(+), 57 deletions
From: Søren Sandmann Pedersen
This program tests whether the new triangle support works.
---
test/Makefile.am |6 +-
test/tri-test.c | 48
2 files changed, 53 insertions(+), 1 deletions(-)
create mode 100644 test/tri-test.c
diff
From: Søren Sandmann Pedersen
A CRC32 based test program to check that pixman_composite_trapezoids()
actually works.
---
test/Makefile.am|5 +
test/composite-traps-test.c | 253 +++
2 files changed, 258 insertions(+), 0 deletions
From: Søren Sandmann Pedersen
The Render X extension can draw triangles as well as trapezoids, but
the implementation has always converted them to trapezoids. This patch
moves the X server's triangle conversion code into pixman, where we
can reuse the pixman_composite_trapezoid()
Hi,
What follows is six patches for pixman, and three patches for the X
server. Together they move the code for the Trapezoids and Triangles
requests into pixman.
Moving them into pixman has some advantages:
- It is a performance improvement in itself since it avoids a call to
image_from_pict
From: Søren Sandmann Pedersen
This function is an implementation of the X server request
Trapezoids. That request is what the X backend of cairo is using all
the time; by moving it into pixman we can hopefully make it faster.
---
pixman/pixman-trap.c | 87
The fb version simply calls the new pixman_composite_triangles(). This
allows us to get rid of miCreateAlphaPicture().
---
fb/fbpict.c |1 +
fb/fbpict.h | 10 ++
fb/fbtrap.c | 87 +++
render/mipict.c |2 +-
render/mipi
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
This program tests whether the new triangle support works.
---
test/Makefile.am |6 +-
test/tri-test.c | 48
2 files changed, 53 insertions(+), 1 deletions(-)
create mode 100644 test/tri-test.c
diff --git a/test/Makefile.am b/test/Makef
The Render X extension can draw triangles as well as trapezoids, but
the implementation has always converted them to trapezoids. This patch
moves the X server's triangle conversion code into pixman, where we
can reuse the pixman_composite_trapezoid() code.
---
pixman/pixman-trap.c | 136 +
This function is an implementation of the X server request
Trapezoids. That request is what the X backend of cairo is using all
the time; by moving it into pixman we can hopefully make it faster.
---
pixman/pixman-trap.c | 87 ++
pixman/pixman.h
Hi,
What follows is three patches for pixman, and two patches for the X
server. Together they move the code for the Trapezoids and Triangles
requests into pixman. Trapezoids is the request that the cairo xlib
backend uses for essentially all its rendering.
By moving it into pixman, I think it wil
From: Søren Sandmann Pedersen
All of these definitions were unused since compositing moved to pixman.
---
fb/fbpict.h| 380
fb/wfbrename.h |1 -
2 files changed, 0 insertions(+), 381 deletions(-)
diff --git a/fb/fbpict.h b/fb
From: Søren Sandmann Pedersen
This function was an unused and trivial wrapper around fbComposite().
---
fb/fbpict.c | 19 ---
fb/fbpict.h | 16
2 files changed, 0 insertions(+), 35 deletions(-)
diff --git a/fb/fbpict.c b/fb/fbpict.c
index 3bc141b..7636040
From: Søren Sandmann Pedersen
These functions haven't existed in a while.
---
fb/wfbrename.h | 15 ---
1 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/fb/wfbrename.h b/fb/wfbrename.h
index f3beed8..5846052 100644
--- a/fb/wfbrename.h
+++ b/fb/wfbrename.h
@@ -
From: Søren Sandmann Pedersen
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.
---
fb/fbpict.h |3 -
fb/fbtrap.c |1 -
render/Makefile.am |5 +-
render/renderedge.c
From: Søren Sandmann Pedersen
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.
---
fb/fbpict.c| 106
fb/fbpict.h
These patches delete a bunch of stuff in fb that has not been used
since compositing moved to pixman. Most of it has survived only
because breaking the server ABI was not allowed at the time.
I don't believe there are any users of any of it in the server or in
the open source drivers.
Soren
___
93 matches
Mail list logo
