Re: Performance of XRenderCompositeTrapezoids in the aliased case

[Michel Dänzer]

On Tue, 2009-02-03 at 04:10 +0200, Mart Raudsepp wrote:
 On Mon, 2009-02-02 at 21:28 +0100, Rémi Cardona wrote:
  Le 02/02/2009 19:52, Clemens Eisserer a écrit :
   2.) What do you think about a data structure where EXA drivers could
   tell EXA which features they support.
   This way EXA could e.g. choose to use A8 instead of A1 only when it
   really needed?
   This could help in various cases to decide which route to go.
  
  I think Geode users would love to see this since the HW doesn't even do 
  A8 but only ARGB32, and for them, the glyph cache was major regression 
  since it uses a lot of A8 pixmaps.
 
 Yeah, it might make sense to have such a way to signal common EXA code
 of what surface types are supported in hardware and perhaps some other
 features or limitations.

There's already driver flags which could be extended. However, I'm not
sure that's even necessary in this particular case; the EXA core might
be able to find out if the driver supports rendering to A8 simply by
calling the CheckComposite driver hook during startup.


 I shamefully admit I haven't actually gotten around to pinpoint this
 glyph perf regression with 101% certainty at Pict_A8 OpAdd's, but
 logically that should be the case.

Yeah, it's likely; it's the key part which provides most of the cache
speedup, so if it can't be accelerated, the glyph cache is degraded to
mostly overhead.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xf86-input-evdev: Changes to 'master'

[Peter Hutterer]

On Mon, Feb 02, 2009 at 10:39:27PM -0800, Dan Nicholson wrote:
 On Mon, Feb 2, 2009 at 7:23 PM, Peter Hutterer peter.hutte...@who-t.net 
 wrote:
  On Tue, Feb 03, 2009 at 01:13:35AM -0200, Paulo César Pereira de Andrade 
  wrote:
 But I think a better approach should be found for pkg-config
   variables, as creating a configure option is basically only to
   correct make distcheck.
  
   can you please explain what's wrong with make distcheck that it requires
   fixing?
 
make distcheck can be seen as a test of a build and install in
  a controlled environment. It checks if the tarball contains all
  the files required to build the package, among other tests.
 
The problem in the xf86-input-evdev was it attempting to install
  files outside of DESTDIR. Actually, if you run make distcheck as
  root user, it will work. As will it work if you specify a wrong
  destdir but with correct permissions (usually a path not starting
  with / and installing in the build directory), and not cause any
  warnings.
 
  It will also work if you set up the PKG_CONFIG_PATH correctly.
 
  The properties header file is installed where the xserver installs the same
  header file (xserver-properties.h).
  Yes, this may be outside of the prefix, but it's where the other xorg header
  files go too. AFAIC this is the right place to put them.
 
 It is the right place to put them. However, part of the distcheck
 process is checking that make install only installs files under
 $prefix. I say that's a stupid check, but I also think that having
 distcheck pass is a good thing because it uncovers a lot of packaging
 bugs. AFAIK, there isn't a way to override that part of distcheck.
 
  I'm happy to add* a configure-time option for those that want the header
  somewhere else. But auto-guessing just to fix make distcheck on your 
  machine
  is not the right thing to do. And I would have appreciated if you would have
  sent the patch to the list for review first before breaking evdev.
 
 Attached is a patch that should add the appropriate workaround. No
 help text is added for the --with-sdkdir option so that people don't
 get the idea that they want to use this option.

applied the patch locally, ran make distcheck and it still fails. Am I doing
anything wrong?
AFAICT from a quick peek, ${includedir} isn't expanded. Can you double-check
this please?

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xf86-input-evdev: Changes to 'master'

[Dan Nicholson]

On Tue, Feb 3, 2009 at 2:13 AM, Peter Hutterer peter.hutte...@who-t.net wrote:
 On Mon, Feb 02, 2009 at 10:39:27PM -0800, Dan Nicholson wrote:
 On Mon, Feb 2, 2009 at 7:23 PM, Peter Hutterer peter.hutte...@who-t.net 
 wrote:
  On Tue, Feb 03, 2009 at 01:13:35AM -0200, Paulo César Pereira de Andrade 
  wrote:
 But I think a better approach should be found for pkg-config
   variables, as creating a configure option is basically only to
   correct make distcheck.
  
   can you please explain what's wrong with make distcheck that it requires
   fixing?
 
make distcheck can be seen as a test of a build and install in
  a controlled environment. It checks if the tarball contains all
  the files required to build the package, among other tests.
 
The problem in the xf86-input-evdev was it attempting to install
  files outside of DESTDIR. Actually, if you run make distcheck as
  root user, it will work. As will it work if you specify a wrong
  destdir but with correct permissions (usually a path not starting
  with / and installing in the build directory), and not cause any
  warnings.
 
  It will also work if you set up the PKG_CONFIG_PATH correctly.
 
  The properties header file is installed where the xserver installs the same
  header file (xserver-properties.h).
  Yes, this may be outside of the prefix, but it's where the other xorg 
  header
  files go too. AFAIC this is the right place to put them.

 It is the right place to put them. However, part of the distcheck
 process is checking that make install only installs files under
 $prefix. I say that's a stupid check, but I also think that having
 distcheck pass is a good thing because it uncovers a lot of packaging
 bugs. AFAIK, there isn't a way to override that part of distcheck.

  I'm happy to add* a configure-time option for those that want the header
  somewhere else. But auto-guessing just to fix make distcheck on your 
  machine
  is not the right thing to do. And I would have appreciated if you would 
  have
  sent the patch to the list for review first before breaking evdev.

 Attached is a patch that should add the appropriate workaround. No
 help text is added for the --with-sdkdir option so that people don't
 get the idea that they want to use this option.

 applied the patch locally, ran make distcheck and it still fails. Am I doing
 anything wrong?
 AFAICT from a quick peek, ${includedir} isn't expanded. Can you double-check
 this please?

That part worked for me, but it does fail on ChangeLog somehow.
${includedir} gets expanded by make eventually. Look at the generated
Makefile. All the derived directories like bindir are similar unless
you've explicitly set it from configure. How is it failing for you?

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: question about building mesa with the two scripts from Xorg wikis

[Dan Nicholson]

On Tue, Feb 3, 2009 at 6:18 AM, Joe Smith stop...@yahoo.com wrote:
 Hi,

 I noticed a discrepancy in the Xorg documentation that's been causing me some 
 confusion:

 At http://wiki.x.org/wiki/ModularDevelopersGuide:
 When using the build.sh script, it says:
 If you want to include Mesa/OpenGL support in the X server, you will need 
 unpack the Mesa source code and pass the directory of the Mesa sources to the 
 build.sh script.
 And you pass the mesa directory like this:
 -m path-to-mesa-sources-for-xserver : full path to Mesa sources

 Also, in the build.sh script, building the mesa sources is commented out, 
 like this:  #build mesa mesa.

 While at http://www.x.org/wiki/Development/git:
 The mesa sources are built before the xserver, and the sources directory is 
 *not* passed to the xserver build directives.

 So the questions are:
 1) Does mesa need to be built separately, as demonstrated in the second link? 
  If so, why is it commented out in build.sh?
 2) Should the --with-mesa-source parameter always be used, and if so, why is 
 it not used in the second link?

Mesa should be built before the server, and it's no longer necessary
to use the -m/--with-mesa-source flag. The server will pick up the
installed headers it needs from mesa. The first page is out of date.

I have no idea why it's commented out in build.sh. You can certainly
uncomment it and give it a whirl. Building mesa should be about as
simple as ./configure. Development/git has a little more info about
that.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: question about building mesa with the two scripts from Xorg wikis

[Jacek Luczak]

Hi

Joe Smith pisze:
 Hi,
 
 So the questions are: 
 1) Does mesa need to be built separately, as demonstrated in the second link? 
  If so, why is it commented out in build.sh?

Yep, it does.

 2) Should the --with-mesa-source parameter always be used, and if so, why is 
 it not used in the second link?

This is not needed any more, see commit 
64f924fbf513b5f91b3f2bcf5767f6fe927d3f7a:

Kill off --with-mesa-source completely
There were a few spots left in the source that were using the --with-mesa-source
defined headers or the now removed $(top_srcdir)/GL directory. These aren't
needed anymore as all the necessary source for GLX is in $(top_srcdir)/glx.

Signed-off-by: Dan Nicholson dbn.li...@gmail.com

Link:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=64f924fbf513b5f91b3f2bcf5767f6fe927d3f7a

-Jacek
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: XtDisplayToApplicationContext fails with Error: Couldn't find per display information

[Dan Nicholson]

On Thu, Jan 29, 2009 at 5:08 PM, Tristan Schmelcher
tschmelc...@google.com wrote:
 Hello all. Sorry if this is not the right place to send this, but I'm
 developing a plugin for Firefox on Linux and I've run up against a
 roadblock. In my plugin I'm being passed a pointer to an X Display struct
 (in NPP_SetWindow, for those of you that know NPAPI) and I'm calling
 XtDisplayToApplicationContext on it to get an app context to use in various
 Xt calls. Now on most systems this works fine--e.g., Ubuntu Dapper 32-bit
 with FF2 and Intrepid 32-bit with FF3 both work flawlessly. However, when I
 build a 64-bit version and try it on Ubuntu Hardy 64-bit with FF3, it
 doesn't work. When it enters XtDisplayToApplicationContext, I get Error:
 Couldn't find per display information on the console and the program exits.

I think that happens when you pass a NULL Display to
XtDisplayToApplicationContext.

I can't say I know anything about Xt, but does it fail in a simple testcase?

#include X11/Xlib.h
#include X11/Intrinsic.h
#include stdio.h
#include stdlib.h

int main(int argc, char *argv[])
{
Display *dpy;
XtAppContext ctx;

dpy = XOpenDisplay(NULL);
if (!dpy) {
fprintf(stderr, XOpenDisplay failed\n);
exit(1);
}
ctx = XtDisplayToApplicationContext(dpy);
XCloseDisplay(dpy);

return 0;
}

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: XtDisplayToApplicationContext fails with Error: Couldn't find per display information

[Tristan Schmelcher]

I've already verified that the display is not NULL. I'll try the experiment
you suggested though. Thanks.

2009/2/3 Dan Nicholson dbn.li...@gmail.com

 On Thu, Jan 29, 2009 at 5:08 PM, Tristan Schmelcher
 tschmelc...@google.com wrote:
  Hello all. Sorry if this is not the right place to send this, but I'm
  developing a plugin for Firefox on Linux and I've run up against a
  roadblock. In my plugin I'm being passed a pointer to an X Display
 struct
  (in NPP_SetWindow, for those of you that know NPAPI) and I'm calling
  XtDisplayToApplicationContext on it to get an app context to use in
 various
  Xt calls. Now on most systems this works fine--e.g., Ubuntu Dapper 32-bit
  with FF2 and Intrepid 32-bit with FF3 both work flawlessly. However, when
 I
  build a 64-bit version and try it on Ubuntu Hardy 64-bit with FF3, it
  doesn't work. When it enters XtDisplayToApplicationContext, I get Error:
  Couldn't find per display information on the console and the program
 exits.

 I think that happens when you pass a NULL Display to
 XtDisplayToApplicationContext.

 I can't say I know anything about Xt, but does it fail in a simple
 testcase?

 #include X11/Xlib.h
 #include X11/Intrinsic.h
 #include stdio.h
 #include stdlib.h

 int main(int argc, char *argv[])
 {
Display *dpy;
XtAppContext ctx;

dpy = XOpenDisplay(NULL);
if (!dpy) {
fprintf(stderr, XOpenDisplay failed\n);
exit(1);
}
ctx = XtDisplayToApplicationContext(dpy);
XCloseDisplay(dpy);

return 0;
 }

 --
 Dan

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Xorg memory leakage?

[Stefano Avallone]

Hi all,

I'm using xorg packages from experimental (xserver 1.5.99.901, libdrm 2.4.3, 
mesa 7.3-rc3, video-intel 2.6.1) and kde 4.2 (from experimental as well).
I am using UXA+DRI2 and kwin with composite effects enabled.
I am able to suspend and resume without problems.

However, I noticed that the memory usage of Xorg slowly increases. After a 
couple of days of usage (with suspend and resume), top shows that the memory 
usage of Xorg is around 30% (I have 2GB RAM). At some point, the laptop 
becomes very slow, kwin automatically disables effects and I need to restart 
the server.

Any advice how I could better debug this issue and provide useful information? 

Many thanks in advance,
Stefano

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xorg memory leakage?

[Stefano Avallone]

On Tuesday 03 February 2009 18:44:17 Stefano Avallone wrote:
 Hi all,

 I'm using xorg packages from experimental (xserver 1.5.99.901, libdrm

*debian* experimental

sorry

 2.4.3, mesa 7.3-rc3, video-intel 2.6.1) and kde 4.2 (from experimental as
 well). I am using UXA+DRI2 and kwin with composite effects enabled.
 I am able to suspend and resume without problems.

 However, I noticed that the memory usage of Xorg slowly increases. After a
 couple of days of usage (with suspend and resume), top shows that the
 memory usage of Xorg is around 30% (I have 2GB RAM). At some point, the
 laptop becomes very slow, kwin automatically disables effects and I need to
 restart the server.

 Any advice how I could better debug this issue and provide useful
 information?

 Many thanks in advance,
 Stefano

 ___
 xorg mailing list
 xorg@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/xorg

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

RandR 1.1 and 1.3 compatibility.

[Ander Conselvan de Oliveira]

Hi,

I'm having a problem with xrandr 1.2.99.4, X server from 1.6 branch and 
drivers that only support RandR 1.1. The server reports it supports version 
1.3 of the extension, so xrandr tries to get panning information but the call 
to XRRGetPanning fails because rrGetPanning private screen function is not 
implemented and returns BarCrtc.

Tricking xrandr to believe the server does not support version 1.3 of the 
extension solves the problem but I guess there should be a better way to 
handle this. Any ideas?

Thanks,
Ander
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xorg memory leakage?

[Peter Harris]

Stefano Avallone wrote:
 Hi all,
 
 I'm using xorg packages from experimental (xserver 1.5.99.901, libdrm 2.4.3, 
 mesa 7.3-rc3, video-intel 2.6.1) and kde 4.2 (from experimental as well).
 I am using UXA+DRI2 and kwin with composite effects enabled.
 I am able to suspend and resume without problems.
 
 However, I noticed that the memory usage of Xorg slowly increases. After a 
 couple of days of usage (with suspend and resume), top shows that the memory 
 usage of Xorg is around 30% (I have 2GB RAM). At some point, the laptop 
 becomes very slow, kwin automatically disables effects and I need to restart 
 the server.
 
 Any advice how I could better debug this issue and provide useful 
 information? 

Start with xrestop. It will give you a good idea of which apps are
really responsible for the memory usage of Xorg.

If xrestop comes up empty, then we can take a closer look at the X
server itself.

Peter Harris
-- 
   Open Text Connectivity Solutions Group
Peter Harrishttp://www.opentext.com/connectivity
Research and DevelopmentPhone: +1 905 762 6001
phar...@opentext.comToll Free: 1 877 359 4866
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 6/9] exa: wrap the remainder of exa_unaccel.c

[Maarten Maathuis]

---
 exa/exa_unaccel.c |   30 +++---
 1 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/exa/exa_unaccel.c b/exa/exa_unaccel.c
index d56f589..a521497 100644
--- a/exa/exa_unaccel.c
+++ b/exa/exa_unaccel.c
@@ -290,9 +290,14 @@ ExaCheckGetSpans (DrawablePtr pDrawable,
 int nspans,
 char *pdstStart)
 {
+ScreenPtr pScreen = pDrawable-pScreen;
+ExaScreenPriv(pScreen);
+
 EXA_FALLBACK((from %p (%c)\n, pDrawable, 
exaDrawableLocation(pDrawable)));
 exaPrepareAccess (pDrawable, EXA_PREPARE_SRC);
-fbGetSpans (pDrawable, wMax, ppt, pwidth, nspans, pdstStart);
+swap(pExaScr, pScreen, GetSpans);
+pScreen-GetSpans (pDrawable, wMax, ppt, pwidth, nspans, pdstStart);
+swap(pExaScr, pScreen, GetSpans);
 exaFinishAccess (pDrawable, EXA_PREPARE_SRC);
 }
 
@@ -310,6 +315,11 @@ ExaCheckComposite (CARD8  op,
CARD16 width,
CARD16 height)
 {
+ScreenPtr pScreen = pDst-pDrawable-pScreen;
+#ifdef RENDER
+PictureScreenPtr   ps = GetPictureScreen(pScreen);
+#endif /* RENDER */
+ExaScreenPriv(pScreen);
 RegionRec region;
 int xoff, yoff;
 
@@ -338,7 +348,9 @@ ExaCheckComposite (CARD8  op,
exaPrepareAccess (pSrc-pDrawable, EXA_PREPARE_SRC);
 if (pMask  pMask-pDrawable != NULL)
exaPrepareAccess (pMask-pDrawable, EXA_PREPARE_MASK);
-fbComposite (op,
+#ifdef RENDER
+swap(pExaScr, ps, Composite);
+ps-Composite (op,
  pSrc,
  pMask,
  pDst,
@@ -350,6 +362,8 @@ ExaCheckComposite (CARD8  op,
  yDst,
  width,
  height);
+swap(pExaScr, ps, Composite);
+#endif /* RENDER */
 if (pMask  pMask-pDrawable != NULL)
exaFinishAccess (pMask-pDrawable, EXA_PREPARE_MASK);
 if (pSrc-pDrawable != NULL)
@@ -366,10 +380,20 @@ ExaCheckAddTraps (PicturePtr  pPicture,
  int   ntrap,
  xTrap *traps)
 {
+ScreenPtr pScreen = pPicture-pDrawable-pScreen;
+#ifdef RENDER
+PictureScreenPtr   ps = GetPictureScreen(pScreen);
+#endif /* RENDER */
+ExaScreenPriv(pScreen);
+
 EXA_FALLBACK((to pict %p (%c)\n,
  exaDrawableLocation(pPicture-pDrawable)));
 exaPrepareAccess(pPicture-pDrawable, EXA_PREPARE_DEST);
-fbAddTraps (pPicture, x_off, y_off, ntrap, traps);
+#ifdef RENDER
+swap(pExaScr, ps, AddTraps);
+ps-AddTraps (pPicture, x_off, y_off, ntrap, traps);
+swap(pExaScr, ps, AddTraps);
+#endif /* RENDER */
 exaFinishAccess(pPicture-pDrawable, EXA_PREPARE_DEST);
 }
 
-- 
1.6.1.1

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 9/9] exa: fix exaCopyArea and friends.

[Maarten Maathuis]

---
 exa/Makefile.am |3 ++-
 exa/exa_accel.c |   44 ++--
 exa/exa_priv.h  |6 +-
 exa/exa_render.c|   14 --
 exa/exa_unaccel.c   |   15 +++
 fb/fbcopy_helpers.h |5 +
 6 files changed, 69 insertions(+), 18 deletions(-)

diff --git a/exa/Makefile.am b/exa/Makefile.am
index 2b3f1e4..f344a05 100644
--- a/exa/Makefile.am
+++ b/exa/Makefile.am
@@ -12,11 +12,12 @@ INCLUDES = \
$(XORG_INCS) \
-I$(srcdir)/../miext/cw
 
-AM_CFLAGS = $(XORG_CFLAGS) $(DIX_CFLAGS)
+AM_CFLAGS = $(XORG_CFLAGS) $(DIX_CFLAGS) -DEXA_WRAPPER
 
 libexa_la_SOURCES = \
exa.c \
exa.h \
+   ../fb/fbcopy_helpers.c \
exa_accel.c \
exa_glyphs.c \
exa_migration.c \
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index 02858f1..db79cee 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -359,7 +359,7 @@ exaCopyNtoNTwoDir (DrawablePtr pSrcDrawable, DrawablePtr 
pDstDrawable,
 return TRUE;
 }
 
-void
+Bool
 exaCopyNtoN (DrawablePtrpSrcDrawable,
 DrawablePtrpDstDrawable,
 GCPtr  pGC,
@@ -383,7 +383,7 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
 
 /* avoid doing copy operations if no boxes */
 if (nbox == 0)
-   return;
+   return TRUE;
 
 pSrcPixmap = exaGetDrawablePixmap (pSrcDrawable);
 pDstPixmap = exaGetDrawablePixmap (pDstDrawable);
@@ -492,15 +492,15 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
 goto out;
 
 fallback:
-EXA_FALLBACK((from %p to %p (%c,%c)\n, pSrcDrawable, pDstDrawable,
- exaDrawableLocation(pSrcDrawable),
- exaDrawableLocation(pDstDrawable)));
-exaPrepareAccessReg (pDstDrawable, EXA_PREPARE_DEST, dstregion);
-exaPrepareAccessReg (pSrcDrawable, EXA_PREPARE_SRC, srcregion);
-fbCopyNtoN (pSrcDrawable, pDstDrawable, pGC, pbox, nbox, dx, dy, reverse,
-   upsidedown, bitplane, closure);
-exaFinishAccess (pSrcDrawable, EXA_PREPARE_SRC);
-exaFinishAccess (pDstDrawable, EXA_PREPARE_DEST);
+if (dstregion) {
+   REGION_UNINIT(pScreen, dstregion);
+   REGION_DESTROY(pScreen, dstregion);
+}
+if (srcregion) {
+   REGION_UNINIT(pScreen, srcregion);
+   REGION_DESTROY(pScreen, srcregion);
+}
+return FALSE;
 
 out:
 if (dstregion) {
@@ -511,6 +511,8 @@ out:
REGION_UNINIT(pScreen, srcregion);
REGION_DESTROY(pScreen, srcregion);
 }
+
+return TRUE;
 }
 
 RegionPtr
@@ -518,15 +520,25 @@ exaCopyArea(DrawablePtr pSrcDrawable, DrawablePtr 
pDstDrawable, GCPtr pGC,
int srcx, int srcy, int width, int height, int dstx, int dsty)
 {
 ExaScreenPriv (pDstDrawable-pScreen);
+RegionPtr ret;
+Bool success;
 
 if (pExaScr-swappedOut) {
 return  ExaCheckCopyArea(pSrcDrawable, pDstDrawable, pGC,
  srcx, srcy, width, height, dstx, dsty);
 }
 
-return  fbDoCopy (pSrcDrawable, pDstDrawable, pGC,
+ret = exaDoCopy (pSrcDrawable, pDstDrawable, pGC,
   srcx, srcy, width, height,
-  dstx, dsty, exaCopyNtoN, 0, NULL);
+  dstx, dsty, exaCopyNtoN, 0, NULL, success);
+
+if (!success) {
+   xfree(ret);
+   return ExaCheckCopyArea(pSrcDrawable, pDstDrawable, pGC,
+ srcx, srcy, width, height, dstx, dsty);
+}
+
+return ret;
 }
 
 static void
@@ -865,6 +877,7 @@ exaCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg, 
RegionPtr prgnSrc)
 RegionRec  rgnDst;
 intdx, dy;
 PixmapPtr  pPixmap = (*pWin-drawable.pScreen-GetWindowPixmap) (pWin);
+Bool ret;
 
 dx = ptOldOrg.x - pWin-drawable.x;
 dy = ptOldOrg.y - pWin-drawable.y;
@@ -879,11 +892,14 @@ exaCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg, 
RegionPtr prgnSrc)
  -pPixmap-screen_x, -pPixmap-screen_y);
 #endif
 
-fbCopyRegion (pPixmap-drawable, pPixmap-drawable,
+ret = exaCopyRegion (pPixmap-drawable, pPixmap-drawable,
  NULL,
  rgnDst, dx, dy, exaCopyNtoN, 0, NULL);
 
 REGION_UNINIT(pWin-drawable.pScreen, rgnDst);
+
+if (!ret)
+   ExaCheckCopyWindow(pWin, ptOldOrg, prgnSrc);
 }
 
 static Bool
diff --git a/exa/exa_priv.h b/exa/exa_priv.h
index 6d7c1dd..c555f85 100644
--- a/exa/exa_priv.h
+++ b/exa/exa_priv.h
@@ -55,6 +55,7 @@
 #include glyphstr.h
 #endif
 #include damage.h
+#include fbcopy_helpers.h
 
 #define DEBUG_TRACE_FALL   0
 #define DEBUG_MIGRATE  0
@@ -379,6 +380,9 @@ ExaCheckAddTraps (PicturePtrpPicture,
  int   ntrap,
  xTrap *traps);
 
+void
+ExaCheckCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg, RegionPtr prgnSrc);
+
 /* exa_accel.c */
 
 static _X_INLINE Bool
@@ -465,7 +469,7 @@ RegionPtr
 exaCopyArea(DrawablePtr pSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC,
int srcx, int srcy, 

[PATCH 1/9] exa: Remove one of the many calls directly into the fb layer.

[Maarten Maathuis]

---
 exa/exa_accel.c |   32 ++--
 1 files changed, 6 insertions(+), 26 deletions(-)

diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index f72a08a..b70222a 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -149,6 +149,7 @@ exaDoPutImage (DrawablePtr pDrawable, GCPtr pGC, int depth, 
int x, int y,
 int xoff, yoff;
 int bpp = pDrawable-bitsPerPixel;
 Bool access_prepared = FALSE;
+Bool ret = TRUE;
 
 if (pExaPixmap-accel_blocked)
return FALSE;
@@ -210,33 +211,12 @@ exaDoPutImage (DrawablePtr pDrawable, GCPtr pGC, int 
depth, int x, int y,
src = bits + (y1 - y) * src_stride + (x1 - x) * (bpp / 8);
ok = pExaScr-info-UploadToScreen(pPix, x1 + xoff, y1 + yoff,
   x2 - x1, y2 - y1, src, src_stride);
-   /* If we fail to accelerate the upload, fall back to using unaccelerated
-* fb calls.
+   /* We have to fall back completely, and ignore what has already been 
completed.
+* Messing with the fb layer directly like we used to is completely 
unacceptable.
 */
if (!ok) {
-   FbStip *dst;
-   FbStride dst_stride;
-   int dstBpp;
-   int dstXoff, dstYoff;
-
-   if (!access_prepared) {
-   ExaDoPrepareAccess(pDrawable, EXA_PREPARE_DEST);
-
-   access_prepared = TRUE;
-   }
-
-   fbGetStipDrawable(pDrawable, dst, dst_stride, dstBpp,
- dstXoff, dstYoff);
-
-   fbBltStip((FbStip *)bits + (y1 - y) * (src_stride / sizeof(FbStip)),
- src_stride / sizeof(FbStip),
- (x1 - x) * dstBpp,
- dst + (y1 + dstYoff) * dst_stride,
- dst_stride,
- (x1 + dstXoff) * dstBpp,
- (x2 - x1) * dstBpp,
- y2 - y1,
- GXcopy, FB_ALLONES, dstBpp);
+   ret = FALSE;
+   break;
}
 }
 
@@ -245,7 +225,7 @@ exaDoPutImage (DrawablePtr pDrawable, GCPtr pGC, int depth, 
int x, int y,
 else
exaMarkSync(pDrawable-pScreen);
 
-return TRUE;
+return ret;
 }
 
 static void
-- 
1.6.1.1

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 5/9] exa: use proper wrapping in exa.c

[Maarten Maathuis]

---
 exa/exa.c |  141 ++---
 1 files changed, 70 insertions(+), 71 deletions(-)

diff --git a/exa/exa.c b/exa/exa.c
index 42b664f..5faeee0 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -188,6 +188,7 @@ exaDestroyPixmap (PixmapPtr pPixmap)
 {
 ScreenPtr  pScreen = pPixmap-drawable.pScreen;
 ExaScreenPriv(pScreen);
+Bool ret;
 
 if (pPixmap-refcnt == 1)
 {
@@ -213,7 +214,12 @@ exaDestroyPixmap (PixmapPtr pPixmap)
REGION_UNINIT(pPixmap-drawable.pScreen, pExaPixmap-validSys);
REGION_UNINIT(pPixmap-drawable.pScreen, pExaPixmap-validFB);
 }
-return fbDestroyPixmap (pPixmap);
+
+swap(pExaScr, pScreen, DestroyPixmap);
+ret = pScreen-DestroyPixmap (pPixmap);
+swap(pExaScr, pScreen, DestroyPixmap);
+
+return ret;
 }
 
 static int
@@ -286,12 +292,14 @@ exaCreatePixmap(ScreenPtr pScreen, int w, int h, int 
depth,
 if (w  32767 || h  32767)
return NullPixmap;
 
+swap(pExaScr, pScreen, CreatePixmap);
 if (!pExaScr-info-CreatePixmap) {
-pPixmap = fbCreatePixmap (pScreen, w, h, depth, usage_hint);
+pPixmap = pScreen-CreatePixmap (pScreen, w, h, depth, usage_hint);
 } else {
 driver_alloc = 1;
-pPixmap = fbCreatePixmap(pScreen, 0, 0, depth, usage_hint);
+pPixmap = pScreen-CreatePixmap(pScreen, 0, 0, depth, usage_hint);
 }
+swap(pExaScr, pScreen, CreatePixmap);
 
 if (!pPixmap)
 return NULL;
@@ -322,8 +330,10 @@ exaCreatePixmap(ScreenPtr pScreen, int w, int h, int depth,
 
 pExaPixmap-driverPriv = pExaScr-info-CreatePixmap(pScreen, 
datasize, 0);
 if (!pExaPixmap-driverPriv) {
- fbDestroyPixmap(pPixmap);
- return NULL;
+   swap(pExaScr, pScreen, DestroyPixmap);
+   pScreen-DestroyPixmap (pPixmap);
+   swap(pExaScr, pScreen, DestroyPixmap);
+   return NULL;
 }
 
 (*pScreen-ModifyPixmapHeader)(pPixmap, w, h, 0, 0,
@@ -354,8 +364,10 @@ exaCreatePixmap(ScreenPtr pScreen, int w, int h, int depth,
 pExaPixmap-fb_size = pExaPixmap-fb_pitch * h;
 
 if (pExaPixmap-fb_pitch  131071) {
-fbDestroyPixmap(pPixmap);
-return NULL;
+   swap(pExaScr, pScreen, DestroyPixmap);
+   pScreen-DestroyPixmap (pPixmap);
+   swap(pExaScr, pScreen, DestroyPixmap);
+   return NULL;
 }
 
/* Set up damage tracking */
@@ -364,7 +376,9 @@ exaCreatePixmap(ScreenPtr pScreen, int w, int h, int depth,
pScreen, pPixmap);
 
if (pExaPixmap-pDamage == NULL) {
-   fbDestroyPixmap (pPixmap);
+   swap(pExaScr, pScreen, DestroyPixmap);
+   pScreen-DestroyPixmap (pPixmap);
+   swap(pExaScr, pScreen, DestroyPixmap);
return NULL;
}
 
@@ -760,6 +774,8 @@ static Bool
 exaChangeWindowAttributes(WindowPtr pWin, unsigned long mask)
 {
 Bool ret;
+ScreenPtr pScreen = pWin-drawable.pScreen;
+ExaScreenPriv(pScreen);
 
 if ((mask  CWBackPixmap)  pWin-backgroundState == BackgroundPixmap) 
 exaPrepareAccess(pWin-background.pixmap-drawable, EXA_PREPARE_SRC);
@@ -767,7 +783,9 @@ exaChangeWindowAttributes(WindowPtr pWin, unsigned long 
mask)
 if ((mask  CWBorderPixmap)  pWin-borderIsPixel == FALSE)
 exaPrepareAccess(pWin-border.pixmap-drawable, EXA_PREPARE_MASK);
 
-ret = fbChangeWindowAttributes(pWin, mask);
+swap(pExaScr, pScreen, ChangeWindowAttributes);
+ret = pScreen-ChangeWindowAttributes(pWin, mask);
+swap(pExaScr, pScreen, ChangeWindowAttributes);
 
 if ((mask  CWBorderPixmap)  pWin-borderIsPixel == FALSE)
 exaFinishAccess(pWin-border.pixmap-drawable, EXA_PREPARE_MASK);
@@ -782,9 +800,15 @@ static RegionPtr
 exaBitmapToRegion(PixmapPtr pPix)
 {
 RegionPtr ret;
+ScreenPtr pScreen = pPix-drawable.pScreen;
+ExaScreenPriv(pScreen);
+
 exaPrepareAccess(pPix-drawable, EXA_PREPARE_SRC);
-ret = fbPixmapToRegion(pPix);
+swap(pExaScr, pScreen, BitmapToRegion);
+ret = pScreen-BitmapToRegion(pPix);
+swap(pExaScr, pScreen, BitmapToRegion);
 exaFinishAccess(pPix-drawable, EXA_PREPARE_SRC);
+
 return ret;
 }
 
@@ -795,9 +819,9 @@ exaCreateScreenResources(ScreenPtr pScreen)
 PixmapPtr pScreenPixmap;
 Bool b;
 
-pScreen-CreateScreenResources = pExaScr-SavedCreateScreenResources;
+swap(pExaScr, pScreen, CreateScreenResources);
 b = pScreen-CreateScreenResources(pScreen);
-pScreen-CreateScreenResources = exaCreateScreenResources;
+swap(pExaScr, pScreen, CreateScreenResources);
 
 if (!b)
 return FALSE;
@@ -831,23 +855,26 @@ exaCloseScreen(int i, ScreenPtr pScreen)
 if (ps-Glyphs == exaGlyphs)
exaGlyphsFini(pScreen);
 
-pScreen-CreateGC = pExaScr-SavedCreateGC;
-pScreen-CloseScreen = pExaScr-SavedCloseScreen;
-pScreen-GetImage = pExaScr-SavedGetImage;
-

[PATCH 8/9] fb: split off a few functions into a seperate file and enhance them slightly.

[Maarten Maathuis]

- Compatibility wrappers, if deemed neccesary will come later.
---
 fb/Makefile.am  |3 +-
 fb/fb.h |   37 +-
 fb/fb24_32.c|4 +-
 fb/fbcopy.c |  342 ++-
 fb/fbcopy_helpers.c |  367 +++
 fb/fbcopy_helpers.h |   52 +++
 fb/fboverlay.c  |1 +
 fb/fbwindow.c   |5 +-
 8 files changed, 448 insertions(+), 363 deletions(-)
 create mode 100644 fb/fbcopy_helpers.c
 create mode 100644 fb/fbcopy_helpers.h

diff --git a/fb/Makefile.am b/fb/Makefile.am
index 64e49f3..cfd9364 100644
--- a/fb/Makefile.am
+++ b/fb/Makefile.am
@@ -7,7 +7,7 @@ INCLUDES = \
 AM_CFLAGS = $(DIX_CFLAGS)
 
 if XORG
-sdk_HEADERS = fb.h fbrop.h fboverlay.h wfbrename.h fbpict.h
+sdk_HEADERS = fb.h fbrop.h fboverlay.h wfbrename.h fbpict.h fbcopy_helpers.h
 endif
 
 libfb_la_CFLAGS = $(AM_CFLAGS)
@@ -24,6 +24,7 @@ libfb_la_SOURCES =\
fbbits.h\
fbblt.c \
fbbltone.c  \
+   fbcopy_helpers.c\
fbcopy.c\
fbfill.c\
fbfillrect.c\
diff --git a/fb/fb.h b/fb/fb.h
index 8384315..b0898b0 100644
--- a/fb/fb.h
+++ b/fb/fb.h
@@ -788,7 +788,7 @@ fb24_32GetImage (DrawablePtr pDrawable,
 unsigned long   planeMask,
 char*d);
 
-extern _X_EXPORT void
+extern _X_EXPORT Bool
 fb24_32CopyMtoN (DrawablePtr pSrcDrawable,
 DrawablePtr pDstDrawable,
 GCPtr   pGC,
@@ -1306,7 +1306,7 @@ fbInitVisuals (VisualPtr*visualp,
  * fbcopy.c
  */
 
-typedef void   (*fbCopyProc) (DrawablePtr  pSrcDrawable,
+typedef Bool   (*fbCopyProc) (DrawablePtr  pSrcDrawable,
   DrawablePtr  pDstDrawable,
   GCPtrpGC,
   BoxPtr   pDstBox,
@@ -1318,7 +1318,7 @@ typedef void  (*fbCopyProc) (DrawablePtr  
pSrcDrawable,
   Pixelbitplane,
   void *closure);
 
-extern _X_EXPORT void
+extern _X_EXPORT Bool
 fbCopyNtoN (DrawablePtrpSrcDrawable,
DrawablePtr pDstDrawable,
GCPtr   pGC,
@@ -1331,7 +1331,7 @@ fbCopyNtoN (DrawablePtr   pSrcDrawable,
Pixel   bitplane,
void*closure);
 
-extern _X_EXPORT void
+extern _X_EXPORT Bool
 fbCopy1toN (DrawablePtrpSrcDrawable,
DrawablePtr pDstDrawable,
GCPtr   pGC,
@@ -1344,7 +1344,7 @@ fbCopy1toN (DrawablePtr   pSrcDrawable,
Pixel   bitplane,
void*closure);
 
-extern _X_EXPORT void
+extern _X_EXPORT Bool
 fbCopyNto1 (DrawablePtrpSrcDrawable,
DrawablePtr pDstDrawable,
GCPtr   pGC,
@@ -1357,31 +1357,6 @@ fbCopyNto1 (DrawablePtr  pSrcDrawable,
Pixel   bitplane,
void*closure);
 
-extern _X_EXPORT void
-fbCopyRegion (DrawablePtr   pSrcDrawable,
- DrawablePtr   pDstDrawable,
- GCPtr pGC,
- RegionPtr pDstRegion,
- int   dx,
- int   dy,
- fbCopyProccopyProc,
- Pixel bitPlane,
- void  *closure);
-
-extern _X_EXPORT RegionPtr
-fbDoCopy (DrawablePtr  pSrcDrawable,
- DrawablePtr   pDstDrawable,
- GCPtr pGC,
- int   xIn, 
- int   yIn,
- int   widthSrc, 
- int   heightSrc,
- int   xOut, 
- int   yOut,
- fbCopyProccopyProc,
- Pixel bitplane,
- void  *closure);
- 
 extern _X_EXPORT RegionPtr
 fbCopyArea (DrawablePtrpSrcDrawable,
DrawablePtr pDstDrawable,
@@ -2036,7 +2011,7 @@ fbPositionWindow(WindowPtr pWin, int x, int y);
 extern _X_EXPORT Bool
 fbUnmapWindow(WindowPtr pWindow);
 
-extern _X_EXPORT void
+extern _X_EXPORT Bool
 fbCopyWindowProc (DrawablePtr  pSrcDrawable,
  DrawablePtr   pDstDrawable,
  GCPtr pGC,
diff --git a/fb/fb24_32.c b/fb/fb24_32.c
index 1ebd598..952b9ff 100644
--- a/fb/fb24_32.c
+++ b/fb/fb24_32.c
@@ -472,7 +472,7 @@ fb24_32GetImage (DrawablePtr pDrawable,
 fbFinishAccess (pDrawable);
 }
 
-void
+Bool
 fb24_32CopyMtoN (DrawablePtr pSrcDrawable,
 DrawablePtr pDstDrawable,
 GCPtr   pGC,
@@ -529,6 +529,8 @@ fb24_32CopyMtoN (DrawablePtr pSrcDrawable,
 
 fbFinishAccess (pSrcDrawable);
 fbFinishAccess (pDstDrawable);
+
+return TRUE;
 }
 
 PixmapPtr
diff --git a/fb/fbcopy.c b/fb/fbcopy.c
index b8b0b6a..2f430b7 100644
--- a/fb/fbcopy.c
+++ b/fb/fbcopy.c
@@ -27,8 +27,9 @@
 #include stdlib.h
 
 #include fb.h
+#include fbcopy_helpers.h
 
-void
+Bool
 fbCopyNtoN (DrawablePtrpSrcDrawable,
DrawablePtr pDstDrawable,

Comments about exa patches i just sent

[Maarten Maathuis]

Per request by anholt and others, i have sent the patches as plain text.

The only change from the last set is that i splitted out a few fb
functions into a seperate file, enhanced them slightly and added a few
defines to allow exa to use them. My attempts to split it out into mi,
gave me very strange issues, so if you think you can do better, be my
guest. In hindsight this approach isn't bad either, and is MrCooper
suggested.

One of the questions is (as it says in patch 8), do you deem
compatibility wrappers necessary?

Comments are appreciated as usual.

Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 4/9] exa: properly wrap GC functions

[Maarten Maathuis]

---
 exa/exa.c |  219 
 exa/exa_priv.h|   33 -
 exa/exa_unaccel.c |   98 +---
 3 files changed, 234 insertions(+), 116 deletions(-)

diff --git a/exa/exa.c b/exa/exa.c
index 496b898..42b664f 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -575,86 +575,164 @@ exaFinishAccess(DrawablePtr pDrawable, int index)
 }
 
 /**
- * exaValidateGC() sets the ops to EXA's implementations, which may be
- * accelerated or may sync the card and fall back to fb.
+ * Here begins EXA's GC code.
+ * Do not ever access the fb/mi layer directly.
  */
+
+static void
+exaValidateGC(GCPtr pGC,
+   unsigned long changes,
+   DrawablePtr pDrawable);
+
+static void
+exaDestroyGC(GCPtr pGC);
+
+static void
+exaChangeGC (GCPtr pGC,
+   unsigned long mask);
+
+static void
+exaCopyGC (GCPtr pGCSrc,
+ unsigned long mask,
+ GCPtr  pGCDst);
+
+static void
+exaChangeClip (GCPtr pGC,
+   int type,
+   pointer pvalue,
+   int nrects);
+
+static void
+exaCopyClip(GCPtr pGCDst, GCPtr pGCSrc);
+
+static void
+exaCopyClip(GCPtr pGCDst, GCPtr pGCSrc);
+
 static void
-exaValidateGC (GCPtr pGC, unsigned long changes, DrawablePtr pDrawable)
+exaDestroyClip(GCPtr pGC);
+
+const GCFuncs exaGCFuncs = {
+exaValidateGC,
+exaChangeGC,
+exaCopyGC,
+exaDestroyGC,
+exaChangeClip,
+exaDestroyClip,
+exaCopyClip
+};
+
+/*
+ * This wrapper exists to allow fbValidateGC to work.
+ */
+static PixmapPtr
+exaCreatePixmapWithPrepare(ScreenPtr pScreen, int w, int h, int depth,
+   unsigned usage_hint)
+{
+PixmapPtr pPixmap = exaCreatePixmap(pScreen, w, h, depth, usage_hint);
+
+if (!pPixmap)
+   return NULL;
+
+/* We use MASK, because SRC is already taken. */
+exaPrepareAccess(pPixmap-drawable, EXA_PREPARE_MASK);
+
+return pPixmap;
+}
+
+static void
+exaValidateGC(GCPtr pGC,
+   unsigned long changes,
+   DrawablePtr pDrawable)
 {
 /* fbValidateGC will do direct access to pixmaps if the tiling has changed.
- * Preempt fbValidateGC by doing its work and masking the change out, so
- * that we can do the Prepare/FinishAccess.
+ * Do a few smart things so fbValidateGC can do it's work.
  */
-#ifdef FB_24_32BIT
-if ((changes  GCTile)  fbGetRotatedPixmap(pGC)) {
-   (*pGC-pScreen-DestroyPixmap) (fbGetRotatedPixmap(pGC));
-   fbGetRotatedPixmap(pGC) = 0;
-}
-   
-if (pGC-fillStyle == FillTiled) {
-   PixmapPtr   pOldTile, pNewTile;
 
-   pOldTile = pGC-tile.pixmap;
-   if (pOldTile-drawable.bitsPerPixel != pDrawable-bitsPerPixel)
-   {
-   pNewTile = fbGetRotatedPixmap(pGC);
-   if (!pNewTile ||
-   pNewTile -drawable.bitsPerPixel != pDrawable-bitsPerPixel)
-   {
-   if (pNewTile)
-   (*pGC-pScreen-DestroyPixmap) (pNewTile);
-   /* fb24_32ReformatTile will do direct access of a newly-
-* allocated pixmap.  This isn't a problem yet, since we don't
-* put pixmaps in FB until at least one accelerated EXA op.
-*/
-   exaPrepareAccess(pOldTile-drawable, EXA_PREPARE_SRC);
-   pNewTile = fb24_32ReformatTile (pOldTile,
-   pDrawable-bitsPerPixel);
-   exaPixmapDirty(pNewTile, 0, 0, pNewTile-drawable.width, 
pNewTile-drawable.height);
-   exaFinishAccess(pOldTile-drawable, EXA_PREPARE_SRC);
-   }
-   if (pNewTile)
-   {
-   fbGetRotatedPixmap(pGC) = pOldTile;
-   pGC-tile.pixmap = pNewTile;
-   changes |= GCTile;
-   }
-   }
+ScreenPtr pScreen = pDrawable-pScreen;
+CreatePixmapProcPtr old_ptr = NULL;
+PixmapPtr pTile = NULL;
+EXA_GC_PROLOGUE(pGC);
+if (changes  GCTile) {
+   old_ptr = pScreen-CreatePixmap;
+   pScreen-CreatePixmap = exaCreatePixmapWithPrepare;
+   if (pGC-fillStyle == FillTiled)
+   pTile = pGC-tile.pixmap;
+   if (pTile)
+   exaPrepareAccess(pTile-drawable, EXA_PREPARE_SRC);
 }
-#endif
+exaPrepareAccessGC(pGC);
+(*pGC-funcs-ValidateGC)(pGC, changes, pDrawable);
+exaFinishAccessGC(pGC);
 if (changes  GCTile) {
-   if (!pGC-tileIsPixel  FbEvenTile (pGC-tile.pixmap-drawable.width *
-pDrawable-bitsPerPixel))
-   {
-   exaPrepareAccess(pGC-tile.pixmap-drawable, EXA_PREPARE_SRC);
-   fbPadPixmap (pGC-tile.pixmap);
-   exaFinishAccess(pGC-tile.pixmap-drawable, EXA_PREPARE_SRC);
+   pScreen-CreatePixmap = old_ptr;
+   if (pTile)
+   exaFinishAccess(pTile-drawable, EXA_PREPARE_SRC);
+
+   /* A new tile pixmap was created. */
+   if (pGC-tile.pixmap != pTile  pGC-fillStyle == FillTiled) {
+   

[PATCH 3/9] exa: add GC private

[Maarten Maathuis]

---
 exa/exa.c  |   11 +++
 exa/exa_priv.h |   12 +++-
 2 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/exa/exa.c b/exa/exa.c
index ba063bb..496b898 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -41,6 +41,8 @@ static int exaScreenPrivateKeyIndex;
 DevPrivateKey exaScreenPrivateKey = exaScreenPrivateKeyIndex;
 static int exaPixmapPrivateKeyIndex;
 DevPrivateKey exaPixmapPrivateKey = exaPixmapPrivateKeyIndex;
+static int exaGCPrivateKeyIndex;
+DevPrivateKey exaGCPrivateKey = exaGCPrivateKeyIndex;
 
 #ifdef MITSHM
 static ShmFuncs exaShmFuncs = { NULL, NULL };
@@ -661,6 +663,8 @@ static GCFuncs  exaGCFuncs = {
 static int
 exaCreateGC (GCPtr pGC)
 {
+ExaGCPriv(pGC);
+
 if (!fbCreateGC (pGC))
return FALSE;
 
@@ -890,6 +894,13 @@ exaDriverInit (ScreenPtr   pScreen,
 
 exaDDXDriverInit(pScreen);
 
+if (!dixRequestPrivate(exaGCPrivateKey, sizeof(ExaGCPrivRec))) {
+   LogMessage(X_WARNING,
+  EXA(%d): Failed to allocate GC private\n,
+  pScreen-myNum);
+   return FALSE;
+}
+
 /*
  * Replace various fb screen functions
  */
diff --git a/exa/exa_priv.h b/exa/exa_priv.h
index cc789c6..3b58948 100644
--- a/exa/exa_priv.h
+++ b/exa/exa_priv.h
@@ -173,9 +173,13 @@ typedef struct {
 
 extern DevPrivateKey exaScreenPrivateKey;
 extern DevPrivateKey exaPixmapPrivateKey;
+extern DevPrivateKey exaGCPrivateKey;
 #define ExaGetScreenPriv(s) 
((ExaScreenPrivPtr)dixLookupPrivate((s)-devPrivates, exaScreenPrivateKey))
 #define ExaScreenPriv(s)   ExaScreenPrivPtrpExaScr = 
ExaGetScreenPriv(s)
 
+#define ExaGetGCPriv(gc) ((ExaGCPrivPtr)dixLookupPrivate((gc)-devPrivates, 
exaGCPrivateKey))
+#define ExaGCPriv(gc) ExaGCPrivPtr pExaGC = ExaGetGCPriv(gc)
+
 /** Align an offset to an arbitrary alignment */
 #define EXA_ALIGN(offset, align) (((offset) + (align) - 1) - \
(((offset) + (align) - 1) % (align)))
@@ -236,7 +240,13 @@ typedef struct {
  */
 void *driverPriv;
 } ExaPixmapPrivRec, *ExaPixmapPrivPtr;
- 
+
+typedef struct {
+/* GC values from the layer below. */
+GCOps *ops;
+GCFuncs *funcs;
+} ExaGCPrivRec, *ExaGCPrivPtr;
+
 typedef struct _ExaMigrationRec {
 Bool as_dst;
 Bool as_src;
-- 
1.6.1.1

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] ISO C90: Move declaration to the beginning of the function

[Tomas Carnecky]

devices.c: In function ‘DoChangeKeyboardControl’:
devices.c:1768: warning: ISO C90 forbids mixed declarations and code

Signed-off-by: Tomas Carnecky t...@dbservice.com
---
 dix/devices.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/dix/devices.c b/dix/devices.c
index 6578229..4f85c6d 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -1682,6 +1682,7 @@ DoChangeKeyboardControl (ClientPtr client, DeviceIntPtr 
keybd, XID *vlist,
 int key = DO_ALL;
 BITS32 index2;
 int mask = vmask, i;
+XkbEventCauseRec cause;
 
 ctrl = keybd-kbdfeed-ctrl;
 while (vmask) {
@@ -1765,7 +1766,6 @@ DoChangeKeyboardControl (ClientPtr client, DeviceIntPtr 
keybd, XID *vlist,
return BadValue;
}
 
-XkbEventCauseRec cause;
 XkbSetCauseCoreReq(cause,X_ChangeKeyboardControl,client);
 XkbSetIndicators(keybd,((led == DO_ALL) ? ~0L : (1L(led-1))),
 ctrl.leds, cause);
-- 
1.6.1.2


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Xvesa black magic

[William Tracy]

Hello all,

I'm playing with an Kdrive-based image of mine under Qemu. I built
Xvesa from the 7.3 release of Xorg, as 7.4 seems to have a regression
in TinyX (that's a topic for another email). I'm building the images
using the T2 SDE framework, if that's meaningful to anyone.

Everything compiles fine. I am able to launch Xvesa just fine ... but
I get no mouse input. It does not respond to a ctrl+alt+backspace
signal or a ctrl+alt+Fn signal (which works before the server
starts).

Finally, I resorted to launching:
sleep 30; pkill X
in one console, while launching Xvesa from another console. This at
least allowed me to see the output from Xvesa, after the script killed
the server:

Couldn't find the keyboard driver keybd
Could not init font path element blablabla
Could not init font path element blablabla
X server does not support locale
cannot set locale modifiers
blackbox: managing screen 0 using TrueColor visual 0x21, depth 16
X connection to :0.0 broken (explicit kill or server shutdown).
xinit:  conection to X server lost.

waiting for X server to shut down

The X11 startup script I'm using is:
#!/bin/sh

. /etc/profile # PATH
HOME=/root # ???

# on x86* we usually could use Xvesa, otherwise we rather need Xfbdev
if [ -d /sys/class/graphics/fb0 ]; then
X=Xfbdev
else
X=Xvesa -mode 0x117
fi

cd $home
xinit `which blackbox` -- `which $X` -mouse mouse,/dev/input/mice
-keybd keyboard


I have confirmed that it is Xvesa, and not Xfbdev that is being
launched, and I have tried every conceivable variation on the server
parameters at this point.

Now, what really puzzles me: in spite of the error message, I can
force a response to keyboard input. If I launch an xterm and no window
manager, I can force the xterm to get key focus, and I can type into
it. However, nothing I can do will make the mouse respond to motion or
to clicks.

So, any thoughts on whether this looks like a kernel configuration
issue, a build configuration issue, or just a run-time X configuration
issue?

If anyone is *really* motivated to help :-) I can try to get you a
copy of the image I built and/or the configuration I used to build it.

-- 
William Tracy
afishion...@gmail.com -- wtr...@calpoly.edu
Vice President, Cal Poly Linux Users' Group
http://www.cplug.org

I disapprove of what you say, but I will defend to the death your
right to say it.
-- Evelyn Beatrice Hall, frequently mis-attributed to Voltaire
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] Fix warning: unused variable XXX

[Tomas Carnecky]

events.c:4614: warning: unused variable ‘kbd’
xkbUtils.c:361: warning: unused variable ‘maxKeysPerMod’
xf86Events.c:409: warning: unused variable ‘ke’
generic.c:131: warning: unused variable ‘cs’
generic.c:130: warning: unused variable ‘size’
xf86RandR12.c:591: warning: unused variable ‘crtc’

Signed-off-by: Tomas Carnecky t...@dbservice.com
---
 dix/events.c   |1 -
 hw/xfree86/common/xf86Events.c |1 -
 hw/xfree86/int10/generic.c |3 +--
 hw/xfree86/modes/xf86RandR12.c |1 -
 xkb/xkbUtils.c |2 +-
 5 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/dix/events.c b/dix/events.c
index 0c8d198..2a35aa3 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -4611,7 +4611,6 @@ ProcQueryPointer(ClientPtr client)
 xQueryPointerReply rep;
 WindowPtr pWin, t;
 DeviceIntPtr mouse = PickPointer(client);
-DeviceIntPtr kbd = PickKeyboard(client);
 SpritePtr pSprite;
 int rc;
 REQUEST(xResourceReq);
diff --git a/hw/xfree86/common/xf86Events.c b/hw/xfree86/common/xf86Events.c
index 50a5bf6..592d4e3 100644
--- a/hw/xfree86/common/xf86Events.c
+++ b/hw/xfree86/common/xf86Events.c
@@ -406,7 +406,6 @@ static void
 xf86ReleaseKeys(DeviceIntPtr pDev)
 {
 KeyClassPtr keyc;
-xEvent ke;
 int i, j, nevents, sigstate;
 
 if (!pDev || !pDev-key)
diff --git a/hw/xfree86/int10/generic.c b/hw/xfree86/int10/generic.c
index 0af7c1b..4808108 100644
--- a/hw/xfree86/int10/generic.c
+++ b/hw/xfree86/int10/generic.c
@@ -126,8 +126,7 @@ xf86ExtendedInitInt10(int entityIndex, int Flags)
 int screen;
 legacyVGARec vga;
  
-#ifdef _PC
-int size;
+#if 0
 CARD32 cs;
 #endif
 
diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
index 83a4f4f..ab39329 100644
--- a/hw/xfree86/modes/xf86RandR12.c
+++ b/hw/xfree86/modes/xf86RandR12.c
@@ -588,7 +588,6 @@ xf86RandR12CreateScreenResources (ScreenPtr pScreen)
else
{
xf86OutputPtr   output = config-output[config-compat_output];
-   xf86CrtcPtr crtc = output-crtc;
 
if (output-conf_monitor 
(output-conf_monitor-mon_width   0 
diff --git a/xkb/xkbUtils.c b/xkb/xkbUtils.c
index 807c654..98f9fc5 100644
--- a/xkb/xkbUtils.c
+++ b/xkb/xkbUtils.c
@@ -358,7 +358,7 @@ KeySymsPtr
 XkbGetCoreMap(DeviceIntPtr keybd)
 {
 register int   key,tmp;
-intmaxSymsPerKey,maxKeysPerMod, maxGroup1Width;
+intmaxSymsPerKey, maxGroup1Width;
 XkbDescPtr xkb;
 KeySymsPtr  syms;
 intmaxNumberOfGroups;
-- 
1.6.1.2


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] Fix warning: cast to pointer from integer of different size

[Tomas Carnecky]

Add parenthesis around the whole expression.

Signed-off-by: Tomas Carnecky t...@dbservice.com
---
 glx/indirect_dispatch.c  |2 +-
 glx/indirect_dispatch_swap.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/glx/indirect_dispatch.c b/glx/indirect_dispatch.c
index 6547f5d..6665519 100644
--- a/glx/indirect_dispatch.c
+++ b/glx/indirect_dispatch.c
@@ -3743,7 +3743,7 @@ void __glXDisp_ResetMinmax(GLbyte * pc)
 void __glXDisp_TexImage3D(GLbyte * pc)
 {
 const CARD32 ptr_is_null = *(CARD32 *)(pc + 76);
-const GLvoid * const pixels = (const GLvoid *) (ptr_is_null != 0) ? NULL : 
(pc + 80);
+const GLvoid * const pixels = (const GLvoid *) ((ptr_is_null != 0) ? NULL 
: (pc + 80));
 __GLXpixel3DHeader * const hdr = (__GLXpixel3DHeader *)(pc);
 
 CALL_PixelStorei( GET_DISPATCH(), (GL_UNPACK_SWAP_BYTES,   hdr-swapBytes) 
);
diff --git a/glx/indirect_dispatch_swap.c b/glx/indirect_dispatch_swap.c
index 0b8c27c..3221c80 100644
--- a/glx/indirect_dispatch_swap.c
+++ b/glx/indirect_dispatch_swap.c
@@ -3879,7 +3879,7 @@ void __glXDispSwap_ResetMinmax(GLbyte * pc)
 void __glXDispSwap_TexImage3D(GLbyte * pc)
 {
 const CARD32 ptr_is_null = *(CARD32 *)(pc + 76);
-const GLvoid * const pixels = (const GLvoid *) (ptr_is_null != 0) ? NULL : 
(pc + 80);
+const GLvoid * const pixels = (const GLvoid *) ((ptr_is_null != 0) ? NULL 
: (pc + 80));
 __GLXpixel3DHeader * const hdr = (__GLXpixel3DHeader *)(pc);
 
 CALL_PixelStorei( GET_DISPATCH(), (GL_UNPACK_SWAP_BYTES,   hdr-swapBytes) 
);
-- 
1.6.1.2


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] fbdevHWGetRec() doesn't return the private data

[Tomas Carnecky]

Signed-off-by: Tomas Carnecky t...@dbservice.com
---
 hw/xfree86/fbdevhw/fbdevhw.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/hw/xfree86/fbdevhw/fbdevhw.c b/hw/xfree86/fbdevhw/fbdevhw.c
index 495d88b..3eee070 100644
--- a/hw/xfree86/fbdevhw/fbdevhw.c
+++ b/hw/xfree86/fbdevhw/fbdevhw.c
@@ -155,7 +155,10 @@ fbdevHWFreeRec(ScrnInfoPtr pScrn)
 int
 fbdevHWGetFD(ScrnInfoPtr pScrn)
 {
-fbdevHWPtr fPtr = fbdevHWGetRec(pScrn);
+fbdevHWPtr fPtr;
+
+fbdevHWGetRec(pScrn);
+fPtr = FBDEVHWPTR(pScrn);
 
 return fPtr-fd;
 }
-- 
1.6.1.2


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] Fix warning: braces around scalar initializer

[Tomas Carnecky]

Signed-off-by: Tomas Carnecky t...@dbservice.com
---
 hw/xfree86/common/xf86Bus.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/xfree86/common/xf86Bus.c b/hw/xfree86/common/xf86Bus.c
index 1f8e4de..69f5152 100644
--- a/hw/xfree86/common/xf86Bus.c
+++ b/hw/xfree86/common/xf86Bus.c
@@ -66,7 +66,7 @@ xf86AccessRec AccessNULL = { noopEnableDisable, 
noopEnableDisable, NULL };
 
 xf86CurrentAccessRec xf86CurrentAccess = {NULL,NULL};
 
-BusRec primaryBus = { BUS_NONE, {{0}}};
+BusRec primaryBus = { BUS_NONE, { 0 } };
 
 static Bool xf86ResAccessEnter = FALSE;
 
-- 
1.6.1.2


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] DBUS_API_SUBJECT_TO_CHANGE is already defined on the command line

[Tomas Carnecky]

dbus-core.c:30:1: warning: DBUS_API_SUBJECT_TO_CHANGE redefined
command-line: warning: this is the location of the previous definition

Signed-off-by: Tomas Carnecky t...@dbservice.com
---
 config/dbus-core.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/config/dbus-core.c b/config/dbus-core.c
index b349c6e..4c5e10f 100644
--- a/config/dbus-core.c
+++ b/config/dbus-core.c
@@ -27,7 +27,6 @@
 #include dix-config.h
 #endif
 
-#define DBUS_API_SUBJECT_TO_CHANGE
 #include dbus/dbus.h
 #include sys/select.h
 
-- 
1.6.1.2


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] Explicitly cast the SDK symbols to 'void *'

[Tomas Carnecky]

Two symbols (isItTimeToYield and dispatchException) are declared
as volatile in the source and gcc doesn't like that the modifier
is implicitely removed. Use an explicit cast.

Signed-off-by: Tomas Carnecky t...@dbservice.com
---
 hw/xfree86/loader/sdksyms.sh |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/xfree86/loader/sdksyms.sh b/hw/xfree86/loader/sdksyms.sh
index be0b0ee..b320661 100755
--- a/hw/xfree86/loader/sdksyms.sh
+++ b/hw/xfree86/loader/sdksyms.sh
@@ -399,7 +399,7 @@ BEGIN {
sub(/[^a-zA-Z0-9_].*/, , symbol);
 
#print;
-   printf(%s,\n, symbol);
+   printf((void *) %s,\n, symbol);
 }
 }
 
-- 
1.6.1.2


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?

[Nix]

On 31 Jan 2009, Michel Dänzer said:

 On Fri, 2009-01-30 at 21:59 +, Nix wrote:
 On 30 Jan 2009, Michel Dänzer stated:
 Trying current xf86-video-ati Git might be good, but my main suggestion
 would be to try xserver Git server-1.6-branch with EXA.
 
 OK. Do I need to upgrade Mesa or anything related at the same time? 
 (I'm currently on libdrm 2.4.1, Mesa a few commits past 7.2.0).

 I think that should be fine; if anything 3D related breaks though, you
 can always try upgrading to Mesa 7.3. :)

I dug out from under the pile of crud caused by being the only person in
the company who made it to work when the staggering total of 10cm of
snow fell on south-eastern England (10cm! imagine that! enough to drown
a garden gnome!), and tried it.

I pulled util/macros, proto/randr, proto/input and pixman to git head so
the X server (1.6-branch head) would build and... it doesn't work as
well as I might have hoped:

[dix] Could not init font path element /usr/local/share/fonts, removing from 
list!
[dix] Could not init font path element /usr/lib/X11/fonts, removing from list!
[dix] Could not init font path element /usr/share/fonts/override, removing from 
list!
[dix] Could not init font path element /usr/lib/X11/fonts/100dpi, removing from 
list!
[dix] Could not init font path element /usr/lib/X11/fonts/75dpi, removing from 
list!
[dix] Could not init font path element /usr/lib/X11/fonts/freefont, removing 
from list!
[dix] Could not init font path element /usr/lib/X11/fonts/jmk, removing from 
list!
[dix] Could not init font path element /usr/lib/X11/fonts/local, removing from 
list!
[dix] Could not init font path element /usr/lib/X11/fonts/mathematica, removing 
from list!
[dix] Could not init font path element /usr/lib/X11/fonts/misc, removing from 
list!
[dix] Could not init font path element /usr/lib/X11/fonts/mozilla, removing 
from list!
[dix] Could not init font path element 
/usr/lib/X11/fonts/SillyNamesForAdobeFonts, removing from list!
[dix] Could not init font path element /usr/lib/X11/fonts/Speedo, removing from 
list!
[dix] Could not init font path element /usr/lib/X11/fonts/TeX, removing from 
list!
[dix] Could not init font path element /usr/lib/X11/fonts/TTF, removing from 
list!
[dix] Could not init font path element /usr/lib/X11/fonts/Type1, removing from 
list!
[dix] Could not init font path element /usr/lib/X11/fonts/cyrillic, removing 
from list!
[dix] Could not init font path element /usr/lib/X11/fonts/OTF, removing from 
list!

It's hard to check the scrolling behaviour of antialiased and fixed-point text
when the only font you have is 'fixed' :)

My X.org log is below (just ignore the version mismatches: yes, the kbd
and mouse drivers didn't load, but I can easily fix that by rebuilding
them --- but there's not much point if all my fonts go missing, and I
doubt they went missing because of the missing mouse driver somehow.)

Ideas?

_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/hades:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6

This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the xorg product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.

X.Org X Server 1.5.99.902 (1.6.0 RC 2)
Release Date: 2009-1-30
X Protocol Version 11, Revision 0
Build Operating System: GNU/Linux Nix
Current Operating System: Linux hades 2.6.28.3-dirty #2 PREEMPT Tue Feb 3 
21:54:25 GMT 2009 i686
Build Date: 03 February 2009  09:10:30PM
 
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/Xorg.0.0.log, Time: Tue Feb  3 22:40:21 2009
(==) Using config file: /etc/X11/xorg.conf
(==) ServerLayout MainServer
(**) |--Screen Primary Screen (0)
(**) |   |--Monitor Samsung SyncMaster 223BW
(**) |   |--Device Radeon 9250
(**) |--Input Device Mouse
(**) |--Input Device Keyboard
(**) Option DontZap true
(**) Option AllowEmptyInput false
(**) Option AutoAddDevices false
(**) Option AutoEnableDevices false
(**) Not automatically adding devices
(**) Not automatically enabling devices
(WW) `fonts.dir' not found (or not valid) in /usr/share/fonts.
Entry deleted from font path.
(Run 'mkfontdir' on /usr/share/fonts).
(==) Including the default font path built-ins.
(**) FontPath set to:
/usr/local/share/fonts,
/usr/lib/X11/fonts,
/usr/share/fonts/override,
/usr/lib/X11/fonts/100dpi,

about the exa patches

[Maarten Maathuis]

Found a potential bug in exaValidateGC, which should be fixed now.

I hope the changes are coming to an end. I still need to know if there
are any external users of fbDoCopy that would care for a wrapper. I'm
assuming that functions that changed their return value from void to
Bool pose no issue, but you're welcome to explain if it's not.

@MrCooper: the approach of patch 8 and 9 is ok by you?

Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] Add a prototype for CopyGetMasterEvent()

[Peter Hutterer]

On Wed, Feb 04, 2009 at 12:03:12AM +0100, Tomas Carnecky wrote:
 This function is defined in mi/mieq.c and used in xkb/ddxDevBtn.c,
 hence it needs a prototype.
 
 Signed-off-by: Tomas Carnecky t...@dbservice.com
 ---
  include/input.h |8 
  1 files changed, 8 insertions(+), 0 deletions(-)
 
 diff --git a/include/input.h b/include/input.h
 index 3b7a173..a91e7e9 100644
 --- a/include/input.h
 +++ b/include/input.h
 @@ -474,6 +474,14 @@ extern _X_EXPORT int AllocMasterDevice(ClientPtr client,
  extern _X_EXPORT void DeepCopyDeviceClasses(DeviceIntPtr from,
DeviceIntPtr to);
  
 +extern _X_EXPORT void CopyGetMasterEvent(
 +DeviceIntPtr mdev,
 +DeviceIntPtr sdev,
 +xEvent* original,
 +EventListPtr master,
 +int count
 +);
 +

_X_INTERNAL is the better approach here. CGME should not be visible to anyone
but the server itself.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 7/9] exa: create ExaCheckGetImage

[Maarten Maathuis]

---
 exa/exa_accel.c   |7 +--
 exa/exa_priv.h|4 
 exa/exa_unaccel.c |   30 ++
 3 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index 10e7914..02858f1 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -1201,12 +1201,7 @@ exaGetImage (DrawablePtr pDrawable, int x, int y, int w, 
int h,
 }
 
 fallback:
-EXA_FALLBACK((from %p (%c)\n, pDrawable,
- exaDrawableLocation(pDrawable)));
-
-exaPrepareAccessReg (pDrawable, EXA_PREPARE_SRC, Reg);
-fbGetImage (pDrawable, x, y, w, h, format, planeMask, d);
-exaFinishAccess (pDrawable, EXA_PREPARE_SRC);
+ExaCheckGetImage(pDrawable, x, y, w, h, format, planeMask, d);
 
 out:
 REGION_UNINIT(pScreen, Reg);
diff --git a/exa/exa_priv.h b/exa/exa_priv.h
index a41e5fe..6d7c1dd 100644
--- a/exa/exa_priv.h
+++ b/exa/exa_priv.h
@@ -361,6 +361,10 @@ ExaCheckPushPixels (GCPtr pGC, PixmapPtr pBitmap,
   int w, int h, int x, int y);
 
 void
+ExaCheckGetImage(DrawablePtr pDrawable, int x, int y, int w, int h,
+   unsigned int format, unsigned long planeMask, char *d);
+
+void
 ExaCheckGetSpans (DrawablePtr pDrawable,
 int wMax,
 DDXPointPtr ppt,
diff --git a/exa/exa_unaccel.c b/exa/exa_unaccel.c
index a521497..e0f2ae9 100644
--- a/exa/exa_unaccel.c
+++ b/exa/exa_unaccel.c
@@ -283,6 +283,36 @@ ExaCheckPushPixels (GCPtr pGC, PixmapPtr pBitmap,
 }
 
 void
+ExaCheckGetImage(DrawablePtr pDrawable, int x, int y, int w, int h,
+   unsigned int format, unsigned long planeMask, char *d)
+{
+BoxRec Box;
+RegionRec Reg;
+int xoff, yoff;
+ScreenPtr pScreen = pDrawable-pScreen;
+PixmapPtr pPix = exaGetDrawablePixmap (pDrawable);
+ExaScreenPriv(pScreen);
+
+EXA_FALLBACK((from %p (%c)\n, pDrawable,
+ exaDrawableLocation(pDrawable)));
+
+exaGetDrawableDeltas(pDrawable, pPix, xoff, yoff);
+
+Box.x1 = pDrawable-y + x + xoff;
+Box.y1 = pDrawable-y + y + yoff;
+Box.x2 = Box.x1 + w;
+Box.y2 = Box.y1 + h;
+
+REGION_INIT(pScreen, Reg, Box, 1);
+
+exaPrepareAccessReg (pDrawable, EXA_PREPARE_SRC, Reg);
+swap(pExaScr, pScreen, GetImage);
+pScreen-GetImage (pDrawable, x, y, w, h, format, planeMask, d);
+swap(pExaScr, pScreen, GetImage);
+exaFinishAccess (pDrawable, EXA_PREPARE_SRC);
+}
+
+void
 ExaCheckGetSpans (DrawablePtr pDrawable,
 int wMax,
 DDXPointPtr ppt,
-- 
1.6.1.1

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 4/9] exa: properly wrap GC functions

[Maarten Maathuis]

---
 exa/exa.c |  233 +
 exa/exa_priv.h|   33 +++-
 exa/exa_unaccel.c |   98 ---
 3 files changed, 248 insertions(+), 116 deletions(-)

diff --git a/exa/exa.c b/exa/exa.c
index 496b898..58d1a7d 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -575,86 +575,178 @@ exaFinishAccess(DrawablePtr pDrawable, int index)
 }
 
 /**
- * exaValidateGC() sets the ops to EXA's implementations, which may be
- * accelerated or may sync the card and fall back to fb.
+ * Here begins EXA's GC code.
+ * Do not ever access the fb/mi layer directly.
  */
+
+static void
+exaValidateGC(GCPtr pGC,
+   unsigned long changes,
+   DrawablePtr pDrawable);
+
+static void
+exaDestroyGC(GCPtr pGC);
+
+static void
+exaChangeGC (GCPtr pGC,
+   unsigned long mask);
+
+static void
+exaCopyGC (GCPtr pGCSrc,
+ unsigned long mask,
+ GCPtr  pGCDst);
+
+static void
+exaChangeClip (GCPtr pGC,
+   int type,
+   pointer pvalue,
+   int nrects);
+
 static void
-exaValidateGC (GCPtr pGC, unsigned long changes, DrawablePtr pDrawable)
+exaCopyClip(GCPtr pGCDst, GCPtr pGCSrc);
+
+static void
+exaCopyClip(GCPtr pGCDst, GCPtr pGCSrc);
+
+static void
+exaDestroyClip(GCPtr pGC);
+
+const GCFuncs exaGCFuncs = {
+exaValidateGC,
+exaChangeGC,
+exaCopyGC,
+exaDestroyGC,
+exaChangeClip,
+exaDestroyClip,
+exaCopyClip
+};
+
+/*
+ * This wrapper exists to allow fbValidateGC to work.
+ */
+static PixmapPtr
+exaCreatePixmapWithPrepare(ScreenPtr pScreen, int w, int h, int depth,
+   unsigned usage_hint)
+{
+PixmapPtr pPixmap;
+ExaScreenPriv(pScreen);
+
+/* This swaps between this function and the real upper layer function.
+ * Normally this would swap to the fb layer pointer, this is a very 
special case.
+ */
+swap(pExaScr, pScreen, CreatePixmap);
+pPixmap = pScreen-CreatePixmap(pScreen, w, h, depth, usage_hint);
+swap(pExaScr, pScreen, CreatePixmap);
+
+if (!pPixmap)
+   return NULL;
+
+/* We use MASK, because SRC is already taken. */
+exaPrepareAccess(pPixmap-drawable, EXA_PREPARE_MASK);
+
+return pPixmap;
+}
+
+static void
+exaValidateGC(GCPtr pGC,
+   unsigned long changes,
+   DrawablePtr pDrawable)
 {
 /* fbValidateGC will do direct access to pixmaps if the tiling has changed.
- * Preempt fbValidateGC by doing its work and masking the change out, so
- * that we can do the Prepare/FinishAccess.
+ * Do a few smart things so fbValidateGC can do it's work.
  */
-#ifdef FB_24_32BIT
-if ((changes  GCTile)  fbGetRotatedPixmap(pGC)) {
-   (*pGC-pScreen-DestroyPixmap) (fbGetRotatedPixmap(pGC));
-   fbGetRotatedPixmap(pGC) = 0;
-}
-   
-if (pGC-fillStyle == FillTiled) {
-   PixmapPtr   pOldTile, pNewTile;
 
-   pOldTile = pGC-tile.pixmap;
-   if (pOldTile-drawable.bitsPerPixel != pDrawable-bitsPerPixel)
-   {
-   pNewTile = fbGetRotatedPixmap(pGC);
-   if (!pNewTile ||
-   pNewTile -drawable.bitsPerPixel != pDrawable-bitsPerPixel)
-   {
-   if (pNewTile)
-   (*pGC-pScreen-DestroyPixmap) (pNewTile);
-   /* fb24_32ReformatTile will do direct access of a newly-
-* allocated pixmap.  This isn't a problem yet, since we don't
-* put pixmaps in FB until at least one accelerated EXA op.
-*/
-   exaPrepareAccess(pOldTile-drawable, EXA_PREPARE_SRC);
-   pNewTile = fb24_32ReformatTile (pOldTile,
-   pDrawable-bitsPerPixel);
-   exaPixmapDirty(pNewTile, 0, 0, pNewTile-drawable.width, 
pNewTile-drawable.height);
-   exaFinishAccess(pOldTile-drawable, EXA_PREPARE_SRC);
-   }
-   if (pNewTile)
-   {
-   fbGetRotatedPixmap(pGC) = pOldTile;
-   pGC-tile.pixmap = pNewTile;
-   changes |= GCTile;
-   }
-   }
+ScreenPtr pScreen = pDrawable-pScreen;
+ExaScreenPriv(pScreen);
+CreatePixmapProcPtr old_ptr = NULL;
+PixmapPtr pTile = NULL;
+EXA_GC_PROLOGUE(pGC);
+if (changes  GCTile) {
+   /* save the fb pointer. */
+   old_ptr = pExaScr-SavedCreatePixmap;
+   /* create a new upper layer pointer. */
+   wrap(pExaScr, pScreen, CreatePixmap, exaCreatePixmapWithPrepare);
+   if (pGC-fillStyle == FillTiled)
+   pTile = pGC-tile.pixmap;
+   if (pTile)
+   exaPrepareAccess(pTile-drawable, EXA_PREPARE_SRC);
 }
-#endif
+exaPrepareAccessGC(pGC);
+(*pGC-funcs-ValidateGC)(pGC, changes, pDrawable);
+exaFinishAccessGC(pGC);
 if (changes  GCTile) {
-   if (!pGC-tileIsPixel  FbEvenTile (pGC-tile.pixmap-drawable.width *
-

Re: [PATCH] __GLX_MEM_COPY() is never used on possible NULL pointers

[Peter Hutterer]

On Wed, Feb 04, 2009 at 12:05:57AM +0100, Tomas Carnecky wrote:
 Signed-off-by: Tomas Carnecky t...@dbservice.com
 ---
  glx/unpack.h |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/glx/unpack.h b/glx/unpack.h
 index a1dd17d..675d8cc 100644
 --- a/glx/unpack.h
 +++ b/glx/unpack.h
 @@ -47,7 +47,7 @@
  ** Fetch a double from potentially unaligned memory.
  */
  #ifdef __GLX_ALIGN64
 -#define __GLX_MEM_COPY(dst,src,n)if (src  dst) memcpy(dst,src,n)
 +#define __GLX_MEM_COPY(dst,src,n)memcpy(dst,src,n)
  #define __GLX_GET_DOUBLE(dst,src)__GLX_MEM_COPY(dst,src,8)
  #else
  #define __GLX_GET_DOUBLE(dst,src)(dst) = *((GLdouble*)(src))
 -- 
 1.6.1.2
 
Can you provide a bit more context for this? Why is removing the check
beneficial?

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?

[Dan Nicholson]

On Tue, Feb 3, 2009 at 3:26 PM, Nix n...@esperi.org.uk wrote:
 On 31 Jan 2009, Michel Dänzer said:

 On Fri, 2009-01-30 at 21:59 +, Nix wrote:
 On 30 Jan 2009, Michel Dänzer stated:
 Trying current xf86-video-ati Git might be good, but my main suggestion
 would be to try xserver Git server-1.6-branch with EXA.

 OK. Do I need to upgrade Mesa or anything related at the same time?
 (I'm currently on libdrm 2.4.1, Mesa a few commits past 7.2.0).

 I think that should be fine; if anything 3D related breaks though, you
 can always try upgrading to Mesa 7.3. :)

 I dug out from under the pile of crud caused by being the only person in
 the company who made it to work when the staggering total of 10cm of
 snow fell on south-eastern England (10cm! imagine that! enough to drown
 a garden gnome!), and tried it.

 I pulled util/macros, proto/randr, proto/input and pixman to git head so
 the X server (1.6-branch head) would build and... it doesn't work as
 well as I might have hoped:

 [dix] Could not init font path element /usr/local/share/fonts, removing from 
 list!
 [dix] Could not init font path element /usr/lib/X11/fonts, removing from list!
 [dix] Could not init font path element /usr/share/fonts/override, removing 
 from list!
 [dix] Could not init font path element /usr/lib/X11/fonts/100dpi, removing 
 from list!
 [dix] Could not init font path element /usr/lib/X11/fonts/75dpi, removing 
 from list!
 [dix] Could not init font path element /usr/lib/X11/fonts/freefont, removing 
 from list!
 [dix] Could not init font path element /usr/lib/X11/fonts/jmk, removing from 
 list!
 [dix] Could not init font path element /usr/lib/X11/fonts/local, removing 
 from list!
 [dix] Could not init font path element /usr/lib/X11/fonts/mathematica, 
 removing from list!
 [dix] Could not init font path element /usr/lib/X11/fonts/misc, removing from 
 list!
 [dix] Could not init font path element /usr/lib/X11/fonts/mozilla, removing 
 from list!
 [dix] Could not init font path element 
 /usr/lib/X11/fonts/SillyNamesForAdobeFonts, removing from list!
 [dix] Could not init font path element /usr/lib/X11/fonts/Speedo, removing 
 from list!
 [dix] Could not init font path element /usr/lib/X11/fonts/TeX, removing from 
 list!
 [dix] Could not init font path element /usr/lib/X11/fonts/TTF, removing from 
 list!
 [dix] Could not init font path element /usr/lib/X11/fonts/Type1, removing 
 from list!
 [dix] Could not init font path element /usr/lib/X11/fonts/cyrillic, removing 
 from list!
 [dix] Could not init font path element /usr/lib/X11/fonts/OTF, removing from 
 list!

 It's hard to check the scrolling behaviour of antialiased and fixed-point text
 when the only font you have is 'fixed' :)

 My X.org log is below (just ignore the version mismatches: yes, the kbd
 and mouse drivers didn't load, but I can easily fix that by rebuilding
 them --- but there's not much point if all my fonts go missing, and I
 doubt they went missing because of the missing mouse driver somehow.)

 Ideas?

The output isn't quite what I'd expect, but I think this is because
it's using the builtin fonts only. Try rebuilding the server with
--disable-builtin-fonts, or apply this patch that's a candidate for
1.6:

http://cgit.freedesktop.org/xorg/xserver/commit/?id=49b93df8a3002db7196aa3fc1fd8dca1c12a55d6

I suspect that will get your fixed fonts back.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 5/9] exa: use proper wrapping in exa.c

[Maarten Maathuis]

---
 exa/exa.c |  141 ++---
 1 files changed, 70 insertions(+), 71 deletions(-)

diff --git a/exa/exa.c b/exa/exa.c
index 58d1a7d..033b353 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -188,6 +188,7 @@ exaDestroyPixmap (PixmapPtr pPixmap)
 {
 ScreenPtr  pScreen = pPixmap-drawable.pScreen;
 ExaScreenPriv(pScreen);
+Bool ret;
 
 if (pPixmap-refcnt == 1)
 {
@@ -213,7 +214,12 @@ exaDestroyPixmap (PixmapPtr pPixmap)
REGION_UNINIT(pPixmap-drawable.pScreen, pExaPixmap-validSys);
REGION_UNINIT(pPixmap-drawable.pScreen, pExaPixmap-validFB);
 }
-return fbDestroyPixmap (pPixmap);
+
+swap(pExaScr, pScreen, DestroyPixmap);
+ret = pScreen-DestroyPixmap (pPixmap);
+swap(pExaScr, pScreen, DestroyPixmap);
+
+return ret;
 }
 
 static int
@@ -286,12 +292,14 @@ exaCreatePixmap(ScreenPtr pScreen, int w, int h, int 
depth,
 if (w  32767 || h  32767)
return NullPixmap;
 
+swap(pExaScr, pScreen, CreatePixmap);
 if (!pExaScr-info-CreatePixmap) {
-pPixmap = fbCreatePixmap (pScreen, w, h, depth, usage_hint);
+pPixmap = pScreen-CreatePixmap (pScreen, w, h, depth, usage_hint);
 } else {
 driver_alloc = 1;
-pPixmap = fbCreatePixmap(pScreen, 0, 0, depth, usage_hint);
+pPixmap = pScreen-CreatePixmap(pScreen, 0, 0, depth, usage_hint);
 }
+swap(pExaScr, pScreen, CreatePixmap);
 
 if (!pPixmap)
 return NULL;
@@ -322,8 +330,10 @@ exaCreatePixmap(ScreenPtr pScreen, int w, int h, int depth,
 
 pExaPixmap-driverPriv = pExaScr-info-CreatePixmap(pScreen, 
datasize, 0);
 if (!pExaPixmap-driverPriv) {
- fbDestroyPixmap(pPixmap);
- return NULL;
+   swap(pExaScr, pScreen, DestroyPixmap);
+   pScreen-DestroyPixmap (pPixmap);
+   swap(pExaScr, pScreen, DestroyPixmap);
+   return NULL;
 }
 
 (*pScreen-ModifyPixmapHeader)(pPixmap, w, h, 0, 0,
@@ -354,8 +364,10 @@ exaCreatePixmap(ScreenPtr pScreen, int w, int h, int depth,
 pExaPixmap-fb_size = pExaPixmap-fb_pitch * h;
 
 if (pExaPixmap-fb_pitch  131071) {
-fbDestroyPixmap(pPixmap);
-return NULL;
+   swap(pExaScr, pScreen, DestroyPixmap);
+   pScreen-DestroyPixmap (pPixmap);
+   swap(pExaScr, pScreen, DestroyPixmap);
+   return NULL;
 }
 
/* Set up damage tracking */
@@ -364,7 +376,9 @@ exaCreatePixmap(ScreenPtr pScreen, int w, int h, int depth,
pScreen, pPixmap);
 
if (pExaPixmap-pDamage == NULL) {
-   fbDestroyPixmap (pPixmap);
+   swap(pExaScr, pScreen, DestroyPixmap);
+   pScreen-DestroyPixmap (pPixmap);
+   swap(pExaScr, pScreen, DestroyPixmap);
return NULL;
}
 
@@ -774,6 +788,8 @@ static Bool
 exaChangeWindowAttributes(WindowPtr pWin, unsigned long mask)
 {
 Bool ret;
+ScreenPtr pScreen = pWin-drawable.pScreen;
+ExaScreenPriv(pScreen);
 
 if ((mask  CWBackPixmap)  pWin-backgroundState == BackgroundPixmap) 
 exaPrepareAccess(pWin-background.pixmap-drawable, EXA_PREPARE_SRC);
@@ -781,7 +797,9 @@ exaChangeWindowAttributes(WindowPtr pWin, unsigned long 
mask)
 if ((mask  CWBorderPixmap)  pWin-borderIsPixel == FALSE)
 exaPrepareAccess(pWin-border.pixmap-drawable, EXA_PREPARE_MASK);
 
-ret = fbChangeWindowAttributes(pWin, mask);
+swap(pExaScr, pScreen, ChangeWindowAttributes);
+ret = pScreen-ChangeWindowAttributes(pWin, mask);
+swap(pExaScr, pScreen, ChangeWindowAttributes);
 
 if ((mask  CWBorderPixmap)  pWin-borderIsPixel == FALSE)
 exaFinishAccess(pWin-border.pixmap-drawable, EXA_PREPARE_MASK);
@@ -796,9 +814,15 @@ static RegionPtr
 exaBitmapToRegion(PixmapPtr pPix)
 {
 RegionPtr ret;
+ScreenPtr pScreen = pPix-drawable.pScreen;
+ExaScreenPriv(pScreen);
+
 exaPrepareAccess(pPix-drawable, EXA_PREPARE_SRC);
-ret = fbPixmapToRegion(pPix);
+swap(pExaScr, pScreen, BitmapToRegion);
+ret = pScreen-BitmapToRegion(pPix);
+swap(pExaScr, pScreen, BitmapToRegion);
 exaFinishAccess(pPix-drawable, EXA_PREPARE_SRC);
+
 return ret;
 }
 
@@ -809,9 +833,9 @@ exaCreateScreenResources(ScreenPtr pScreen)
 PixmapPtr pScreenPixmap;
 Bool b;
 
-pScreen-CreateScreenResources = pExaScr-SavedCreateScreenResources;
+swap(pExaScr, pScreen, CreateScreenResources);
 b = pScreen-CreateScreenResources(pScreen);
-pScreen-CreateScreenResources = exaCreateScreenResources;
+swap(pExaScr, pScreen, CreateScreenResources);
 
 if (!b)
 return FALSE;
@@ -845,23 +869,26 @@ exaCloseScreen(int i, ScreenPtr pScreen)
 if (ps-Glyphs == exaGlyphs)
exaGlyphsFini(pScreen);
 
-pScreen-CreateGC = pExaScr-SavedCreateGC;
-pScreen-CloseScreen = pExaScr-SavedCloseScreen;
-pScreen-GetImage = pExaScr-SavedGetImage;
-

Re: Xorg memory leakage?

[Pat Kane]

Can you run xrestop?


On 2/3/09, Stefano Avallone stava...@unina.it wrote:
 On Tuesday 03 February 2009 18:44:17 Stefano Avallone wrote:
 Hi all,

 I'm using xorg packages from experimental (xserver 1.5.99.901, libdrm

 *debian* experimental

 sorry

 2.4.3, mesa 7.3-rc3, video-intel 2.6.1) and kde 4.2 (from experimental as
 well). I am using UXA+DRI2 and kwin with composite effects enabled.
 I am able to suspend and resume without problems.

 However, I noticed that the memory usage of Xorg slowly increases. After a
 couple of days of usage (with suspend and resume), top shows that the
 memory usage of Xorg is around 30% (I have 2GB RAM). At some point, the
 laptop becomes very slow, kwin automatically disables effects and I need
 to
 restart the server.

 Any advice how I could better debug this issue and provide useful
 information?

 Many thanks in advance,
 Stefano

 ___
 xorg mailing list
 xorg@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/xorg

 ___
 xorg mailing list
 xorg@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/xorg

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 1/9] exa: Remove one of the many calls directly into the fb layer.

[Maarten Maathuis]

---
 exa/exa_accel.c |   32 ++--
 1 files changed, 6 insertions(+), 26 deletions(-)

diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index f72a08a..b70222a 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -149,6 +149,7 @@ exaDoPutImage (DrawablePtr pDrawable, GCPtr pGC, int depth, 
int x, int y,
 int xoff, yoff;
 int bpp = pDrawable-bitsPerPixel;
 Bool access_prepared = FALSE;
+Bool ret = TRUE;
 
 if (pExaPixmap-accel_blocked)
return FALSE;
@@ -210,33 +211,12 @@ exaDoPutImage (DrawablePtr pDrawable, GCPtr pGC, int 
depth, int x, int y,
src = bits + (y1 - y) * src_stride + (x1 - x) * (bpp / 8);
ok = pExaScr-info-UploadToScreen(pPix, x1 + xoff, y1 + yoff,
   x2 - x1, y2 - y1, src, src_stride);
-   /* If we fail to accelerate the upload, fall back to using unaccelerated
-* fb calls.
+   /* We have to fall back completely, and ignore what has already been 
completed.
+* Messing with the fb layer directly like we used to is completely 
unacceptable.
 */
if (!ok) {
-   FbStip *dst;
-   FbStride dst_stride;
-   int dstBpp;
-   int dstXoff, dstYoff;
-
-   if (!access_prepared) {
-   ExaDoPrepareAccess(pDrawable, EXA_PREPARE_DEST);
-
-   access_prepared = TRUE;
-   }
-
-   fbGetStipDrawable(pDrawable, dst, dst_stride, dstBpp,
- dstXoff, dstYoff);
-
-   fbBltStip((FbStip *)bits + (y1 - y) * (src_stride / sizeof(FbStip)),
- src_stride / sizeof(FbStip),
- (x1 - x) * dstBpp,
- dst + (y1 + dstYoff) * dst_stride,
- dst_stride,
- (x1 + dstXoff) * dstBpp,
- (x2 - x1) * dstBpp,
- y2 - y1,
- GXcopy, FB_ALLONES, dstBpp);
+   ret = FALSE;
+   break;
}
 }
 
@@ -245,7 +225,7 @@ exaDoPutImage (DrawablePtr pDrawable, GCPtr pGC, int depth, 
int x, int y,
 else
exaMarkSync(pDrawable-pScreen);
 
-return TRUE;
+return ret;
 }
 
 static void
-- 
1.6.1.1

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 2/9] exa: kill of exaImageGlyphBlt

[Maarten Maathuis]

- It serves no obvious purpose, yet it directly accesses many fb
symbols.
---
 exa/exa_accel.c |  135 +--
 1 files changed, 1 insertions(+), 134 deletions(-)

diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index b70222a..10e7914 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -836,139 +836,6 @@ out:
 REGION_DESTROY(pScreen, pReg);
 }
 
-static void
-exaImageGlyphBlt (DrawablePtr  pDrawable,
- GCPtr pGC,
- int   x,
- int   y,
- unsigned int  nglyph,
- CharInfoPtr   *ppciInit,
- pointer   pglyphBase)
-{
-FbGCPrivPtrpPriv = fbGetGCPrivate(pGC);
-CharInfoPtr*ppci;
-CharInfoPtrpci;
-unsigned char   *pglyph;   /* pointer bits in glyph */
-intgWidth, gHeight;/* width and height of glyph */
-FbStride   gStride;/* stride of glyph */
-Bool   opaque;
-intgx, gy;
-void   (*glyph) (FbBits *,
- FbStride,
- int,
- FbStip *,
- FbBits,
- int,
- int);
-FbBits *dst;
-FbStride   dstStride;
-intdstBpp;
-intdstXoff, dstYoff;
-FbBits depthMask;
-PixmapPtr  pPixmap = exaGetDrawablePixmap(pDrawable);
-ExaPixmapPriv(pPixmap);
-RegionPtr  pending_damage = NULL;
-BoxRec extents;
-intxoff, yoff;
-
-if (pExaPixmap-pDamage)
-   pending_damage = DamagePendingRegion(pExaPixmap-pDamage);
-
-if (pending_damage) {
-   extents = *REGION_EXTENTS(pScreen, pending_damage);
-
-   if (extents.x1 = extents.x2 || extents.y1 = extents.y2)
-   return;
-
-   depthMask = FbFullMask(pDrawable-depth);
-}
-
-if (!pending_damage || (pGC-planemask  depthMask) != depthMask)
-{
-   ExaCheckImageGlyphBlt(pDrawable, pGC, x, y, nglyph, ppciInit, 
pglyphBase);
-   return;
-}
-
-glyph = NULL;
-switch (pDrawable-bitsPerPixel) {
-case 8:glyph = fbGlyph8; break;
-case 16:glyph = fbGlyph16; break;
-case 24:glyph = fbGlyph24; break;
-case 32:glyph = fbGlyph32; break;
-}
-
-x += pDrawable-x;
-y += pDrawable-y;
-
-exaGetDrawableDeltas(pDrawable, pPixmap, xoff, yoff);
-extents.x1 -= xoff;
-extents.x2 -= xoff;
-extents.y1 -= yoff;
-extents.y2 -= yoff;
-
-exaPrepareAccessReg (pDrawable, EXA_PREPARE_DEST, pending_damage);
-
-if (TERMINALFONT (pGC-font)  !glyph)
-{
-   opaque = TRUE;
-}
-else
-{
-   FbBits fg = fbReplicatePixel (pGC-bgPixel, pDrawable-bitsPerPixel);
-
-   fbSolidBoxClipped (pDrawable,
-  fbGetCompositeClip(pGC),
-  extents.x1,
-  extents.y1,
-  extents.x2,
-  extents.y2,
-  fbAnd (GXcopy, fg, pGC-planemask),
-  fbXor (GXcopy, fg, pGC-planemask));
-
-   opaque = FALSE;
-}
-
-EXA_FALLBACK((to %p (%c)\n, pDrawable, exaDrawableLocation(pDrawable)));
-
-exaPrepareAccessGC (pGC);
-
-fbGetDrawable (pDrawable, dst, dstStride, dstBpp, dstXoff, dstYoff);
-
-for (ppci = ppciInit; nglyph; nglyph--, x += pci-metrics.characterWidth)
-{
-   pci = *ppci++;
-   gWidth = GLYPHWIDTHPIXELS(pci);
-   gHeight = GLYPHHEIGHTPIXELS(pci);
-   gx = x + pci-metrics.leftSideBearing;
-   gy = y - pci-metrics.ascent;
-
-   if (!gWidth || !gHeight || (gx + gWidth) = extents.x1 ||
-   (gy + gHeight) = extents.y1 || gx = extents.x2 ||
-   gy = extents.y2)
-   continue;
-
-   pglyph = FONTGLYPHBITS(pglyphBase, pci);
-
-   if (glyph  gWidth = sizeof (FbStip) * 8 
-   fbGlyphIn (fbGetCompositeClip(pGC), gx, gy, gWidth, gHeight))
-   {
-   (*glyph) (dst + (gy + dstYoff) * dstStride, dstStride, dstBpp,
- (FbStip *) pglyph, pPriv-fg, gx + dstXoff, gHeight);
-   }
-   else
-   {
-   RegionPtr pClip = fbGetCompositeClip(pGC);
-
-   gStride = GLYPHWIDTHBYTESPADDED(pci) / sizeof (FbStip);
-   fbPutXYImage (pDrawable, pClip, pPriv-fg, pPriv-bg, pPriv-pm,
- GXcopy, opaque, gx, gy, gWidth, gHeight,
- (FbStip *) pglyph, gStride, 0);
-   }
-}
-exaFinishAccessGC (pGC);
-exaFinishAccess (pDrawable, EXA_PREPARE_DEST);
-}
-
 const GCOps exaOps = {
 exaFillSpans,
 ExaCheckSetSpans,
@@ -987,7 +854,7 @@ const GCOps exaOps = {
 miPolyText16,
 miImageText8,
 miImageText16,
-exaImageGlyphBlt,
+

[PATCH 7/9] exa: create ExaCheckGetImage

[Maarten Maathuis]

---
 exa/exa_accel.c   |7 +--
 exa/exa_priv.h|4 
 exa/exa_unaccel.c |   30 ++
 3 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index 10e7914..02858f1 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -1201,12 +1201,7 @@ exaGetImage (DrawablePtr pDrawable, int x, int y, int w, 
int h,
 }
 
 fallback:
-EXA_FALLBACK((from %p (%c)\n, pDrawable,
- exaDrawableLocation(pDrawable)));
-
-exaPrepareAccessReg (pDrawable, EXA_PREPARE_SRC, Reg);
-fbGetImage (pDrawable, x, y, w, h, format, planeMask, d);
-exaFinishAccess (pDrawable, EXA_PREPARE_SRC);
+ExaCheckGetImage(pDrawable, x, y, w, h, format, planeMask, d);
 
 out:
 REGION_UNINIT(pScreen, Reg);
diff --git a/exa/exa_priv.h b/exa/exa_priv.h
index a41e5fe..6d7c1dd 100644
--- a/exa/exa_priv.h
+++ b/exa/exa_priv.h
@@ -361,6 +361,10 @@ ExaCheckPushPixels (GCPtr pGC, PixmapPtr pBitmap,
   int w, int h, int x, int y);
 
 void
+ExaCheckGetImage(DrawablePtr pDrawable, int x, int y, int w, int h,
+   unsigned int format, unsigned long planeMask, char *d);
+
+void
 ExaCheckGetSpans (DrawablePtr pDrawable,
 int wMax,
 DDXPointPtr ppt,
diff --git a/exa/exa_unaccel.c b/exa/exa_unaccel.c
index a521497..e0f2ae9 100644
--- a/exa/exa_unaccel.c
+++ b/exa/exa_unaccel.c
@@ -283,6 +283,36 @@ ExaCheckPushPixels (GCPtr pGC, PixmapPtr pBitmap,
 }
 
 void
+ExaCheckGetImage(DrawablePtr pDrawable, int x, int y, int w, int h,
+   unsigned int format, unsigned long planeMask, char *d)
+{
+BoxRec Box;
+RegionRec Reg;
+int xoff, yoff;
+ScreenPtr pScreen = pDrawable-pScreen;
+PixmapPtr pPix = exaGetDrawablePixmap (pDrawable);
+ExaScreenPriv(pScreen);
+
+EXA_FALLBACK((from %p (%c)\n, pDrawable,
+ exaDrawableLocation(pDrawable)));
+
+exaGetDrawableDeltas(pDrawable, pPix, xoff, yoff);
+
+Box.x1 = pDrawable-y + x + xoff;
+Box.y1 = pDrawable-y + y + yoff;
+Box.x2 = Box.x1 + w;
+Box.y2 = Box.y1 + h;
+
+REGION_INIT(pScreen, Reg, Box, 1);
+
+exaPrepareAccessReg (pDrawable, EXA_PREPARE_SRC, Reg);
+swap(pExaScr, pScreen, GetImage);
+pScreen-GetImage (pDrawable, x, y, w, h, format, planeMask, d);
+swap(pExaScr, pScreen, GetImage);
+exaFinishAccess (pDrawable, EXA_PREPARE_SRC);
+}
+
+void
 ExaCheckGetSpans (DrawablePtr pDrawable,
 int wMax,
 DDXPointPtr ppt,
-- 
1.6.1.1

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: RandR 1.1 and 1.3 compatibility.

[Colin Guthrie]

'Twas brillig, and Ander Conselvan de Oliveira at 03/02/09 18:21 did 
gyre and gimble:
 Hi,
 
 I'm having a problem with xrandr 1.2.99.4, X server from 1.6 branch and 
 drivers that only support RandR 1.1. The server reports it supports version 
 1.3 of the extension, so xrandr tries to get panning information but the call 
 to XRRGetPanning fails because rrGetPanning private screen function is not 
 implemented and returns BarCrtc.
 
 Tricking xrandr to believe the server does not support version 1.3 of the 
 extension solves the problem but I guess there should be a better way to 
 handle this. Any ideas?

Perhaps related to:
http://bugs.freedesktop.org/show_bug.cgi?id=19337

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] dix: die if we can't activate or init the VCP/VCK.

[Peter Hutterer]

If we have a busted xkb setup, the XKB initialization on the core devices
fails and leaves us with dev-key-xkbInfo == NULL. This in turn causes
segfaults lateron.

Return BadValue when the XKB configuration for a master device failed, and if
that happens for the VCP/VCK, die semi-gracefully.

Reported by Aaron Plattner.

Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
 dix/devices.c |   20 +---
 1 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/dix/devices.c b/dix/devices.c
index 6578229..1c3a0de 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -488,8 +488,13 @@ CoreKeyboardProc(DeviceIntPtr pDev, int what)
 switch (what) {
 case DEVICE_INIT:
 XkbGetRulesDflts(rmlvo);
-InitKeyboardDeviceStruct(pDev, rmlvo, CoreKeyboardBell,
- CoreKeyboardCtl);
+if (!InitKeyboardDeviceStruct(pDev, rmlvo, CoreKeyboardBell,
+  CoreKeyboardCtl))
+{
+ErrorF(Keyboard initialization failed. This could be a missing 
+   or incorrect setup of xkeyboard-config.\n);
+return BadValue;
+}
 return Success;
 
 case DEVICE_ON:
@@ -554,11 +559,12 @@ InitCoreDevices(void)
   inputInfo.keyboard) != Success)
 FatalError(Failed to allocate core devices);
 
-ActivateDevice(inputInfo.pointer);
-ActivateDevice(inputInfo.keyboard);
-EnableDevice(inputInfo.pointer);
-EnableDevice(inputInfo.keyboard);
-
+if (ActivateDevice(inputInfo.pointer) != Success ||
+ActivateDevice(inputInfo.keyboard) != Success)
+FatalError(Failed to activate core devices.);
+if (!EnableDevice(inputInfo.pointer) ||
+!EnableDevice(inputInfo.keyboard))
+FatalError(Failed to enable core devices.);
 }
 
 /**
-- 
1.6.0.6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 9/9] exa: fix exaCopyArea and friends.

[Maarten Maathuis]

---
 exa/Makefile.am |3 ++-
 exa/exa_accel.c |   44 ++--
 exa/exa_priv.h  |6 +-
 exa/exa_render.c|   14 --
 exa/exa_unaccel.c   |   15 +++
 fb/fbcopy_helpers.h |5 +
 6 files changed, 69 insertions(+), 18 deletions(-)

diff --git a/exa/Makefile.am b/exa/Makefile.am
index 2b3f1e4..f344a05 100644
--- a/exa/Makefile.am
+++ b/exa/Makefile.am
@@ -12,11 +12,12 @@ INCLUDES = \
$(XORG_INCS) \
-I$(srcdir)/../miext/cw
 
-AM_CFLAGS = $(XORG_CFLAGS) $(DIX_CFLAGS)
+AM_CFLAGS = $(XORG_CFLAGS) $(DIX_CFLAGS) -DEXA_WRAPPER
 
 libexa_la_SOURCES = \
exa.c \
exa.h \
+   ../fb/fbcopy_helpers.c \
exa_accel.c \
exa_glyphs.c \
exa_migration.c \
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index 02858f1..db79cee 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -359,7 +359,7 @@ exaCopyNtoNTwoDir (DrawablePtr pSrcDrawable, DrawablePtr 
pDstDrawable,
 return TRUE;
 }
 
-void
+Bool
 exaCopyNtoN (DrawablePtrpSrcDrawable,
 DrawablePtrpDstDrawable,
 GCPtr  pGC,
@@ -383,7 +383,7 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
 
 /* avoid doing copy operations if no boxes */
 if (nbox == 0)
-   return;
+   return TRUE;
 
 pSrcPixmap = exaGetDrawablePixmap (pSrcDrawable);
 pDstPixmap = exaGetDrawablePixmap (pDstDrawable);
@@ -492,15 +492,15 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
 goto out;
 
 fallback:
-EXA_FALLBACK((from %p to %p (%c,%c)\n, pSrcDrawable, pDstDrawable,
- exaDrawableLocation(pSrcDrawable),
- exaDrawableLocation(pDstDrawable)));
-exaPrepareAccessReg (pDstDrawable, EXA_PREPARE_DEST, dstregion);
-exaPrepareAccessReg (pSrcDrawable, EXA_PREPARE_SRC, srcregion);
-fbCopyNtoN (pSrcDrawable, pDstDrawable, pGC, pbox, nbox, dx, dy, reverse,
-   upsidedown, bitplane, closure);
-exaFinishAccess (pSrcDrawable, EXA_PREPARE_SRC);
-exaFinishAccess (pDstDrawable, EXA_PREPARE_DEST);
+if (dstregion) {
+   REGION_UNINIT(pScreen, dstregion);
+   REGION_DESTROY(pScreen, dstregion);
+}
+if (srcregion) {
+   REGION_UNINIT(pScreen, srcregion);
+   REGION_DESTROY(pScreen, srcregion);
+}
+return FALSE;
 
 out:
 if (dstregion) {
@@ -511,6 +511,8 @@ out:
REGION_UNINIT(pScreen, srcregion);
REGION_DESTROY(pScreen, srcregion);
 }
+
+return TRUE;
 }
 
 RegionPtr
@@ -518,15 +520,25 @@ exaCopyArea(DrawablePtr pSrcDrawable, DrawablePtr 
pDstDrawable, GCPtr pGC,
int srcx, int srcy, int width, int height, int dstx, int dsty)
 {
 ExaScreenPriv (pDstDrawable-pScreen);
+RegionPtr ret;
+Bool success;
 
 if (pExaScr-swappedOut) {
 return  ExaCheckCopyArea(pSrcDrawable, pDstDrawable, pGC,
  srcx, srcy, width, height, dstx, dsty);
 }
 
-return  fbDoCopy (pSrcDrawable, pDstDrawable, pGC,
+ret = exaDoCopy (pSrcDrawable, pDstDrawable, pGC,
   srcx, srcy, width, height,
-  dstx, dsty, exaCopyNtoN, 0, NULL);
+  dstx, dsty, exaCopyNtoN, 0, NULL, success);
+
+if (!success) {
+   xfree(ret);
+   return ExaCheckCopyArea(pSrcDrawable, pDstDrawable, pGC,
+ srcx, srcy, width, height, dstx, dsty);
+}
+
+return ret;
 }
 
 static void
@@ -865,6 +877,7 @@ exaCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg, 
RegionPtr prgnSrc)
 RegionRec  rgnDst;
 intdx, dy;
 PixmapPtr  pPixmap = (*pWin-drawable.pScreen-GetWindowPixmap) (pWin);
+Bool ret;
 
 dx = ptOldOrg.x - pWin-drawable.x;
 dy = ptOldOrg.y - pWin-drawable.y;
@@ -879,11 +892,14 @@ exaCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg, 
RegionPtr prgnSrc)
  -pPixmap-screen_x, -pPixmap-screen_y);
 #endif
 
-fbCopyRegion (pPixmap-drawable, pPixmap-drawable,
+ret = exaCopyRegion (pPixmap-drawable, pPixmap-drawable,
  NULL,
  rgnDst, dx, dy, exaCopyNtoN, 0, NULL);
 
 REGION_UNINIT(pWin-drawable.pScreen, rgnDst);
+
+if (!ret)
+   ExaCheckCopyWindow(pWin, ptOldOrg, prgnSrc);
 }
 
 static Bool
diff --git a/exa/exa_priv.h b/exa/exa_priv.h
index 6d7c1dd..c555f85 100644
--- a/exa/exa_priv.h
+++ b/exa/exa_priv.h
@@ -55,6 +55,7 @@
 #include glyphstr.h
 #endif
 #include damage.h
+#include fbcopy_helpers.h
 
 #define DEBUG_TRACE_FALL   0
 #define DEBUG_MIGRATE  0
@@ -379,6 +380,9 @@ ExaCheckAddTraps (PicturePtrpPicture,
  int   ntrap,
  xTrap *traps);
 
+void
+ExaCheckCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg, RegionPtr prgnSrc);
+
 /* exa_accel.c */
 
 static _X_INLINE Bool
@@ -465,7 +469,7 @@ RegionPtr
 exaCopyArea(DrawablePtr pSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC,
int srcx, int srcy, 

[PATCH] Add a prototype for CopyGetMasterEvent()

[Tomas Carnecky]

This function is defined in mi/mieq.c and used in xkb/ddxDevBtn.c,
hence it needs a prototype.

Signed-off-by: Tomas Carnecky t...@dbservice.com
---
 include/input.h |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/include/input.h b/include/input.h
index 3b7a173..f1b6a4d 100644
--- a/include/input.h
+++ b/include/input.h
@@ -474,6 +474,14 @@ extern _X_EXPORT int AllocMasterDevice(ClientPtr client,
 extern _X_EXPORT void DeepCopyDeviceClasses(DeviceIntPtr from,
   DeviceIntPtr to);
 
+extern _X_INTERNAL void CopyGetMasterEvent(
+DeviceIntPtr mdev,
+DeviceIntPtr sdev,
+xEvent* original,
+EventListPtr master,
+int count
+);
+
 /* Helper functions. */
 extern int generate_modkeymap(ClientPtr client, DeviceIntPtr dev,
   KeyCode **modkeymap, int *max_keys_per_mod);
-- 
1.6.1.2


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 2/9] exa: kill of exaImageGlyphBlt

[Maarten Maathuis]

- It serves no obvious purpose, yet it directly accesses many fb
symbols.
---
 exa/exa_accel.c |  135 +--
 1 files changed, 1 insertions(+), 134 deletions(-)

diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index b70222a..10e7914 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -836,139 +836,6 @@ out:
 REGION_DESTROY(pScreen, pReg);
 }
 
-static void
-exaImageGlyphBlt (DrawablePtr  pDrawable,
- GCPtr pGC,
- int   x,
- int   y,
- unsigned int  nglyph,
- CharInfoPtr   *ppciInit,
- pointer   pglyphBase)
-{
-FbGCPrivPtrpPriv = fbGetGCPrivate(pGC);
-CharInfoPtr*ppci;
-CharInfoPtrpci;
-unsigned char   *pglyph;   /* pointer bits in glyph */
-intgWidth, gHeight;/* width and height of glyph */
-FbStride   gStride;/* stride of glyph */
-Bool   opaque;
-intgx, gy;
-void   (*glyph) (FbBits *,
- FbStride,
- int,
- FbStip *,
- FbBits,
- int,
- int);
-FbBits *dst;
-FbStride   dstStride;
-intdstBpp;
-intdstXoff, dstYoff;
-FbBits depthMask;
-PixmapPtr  pPixmap = exaGetDrawablePixmap(pDrawable);
-ExaPixmapPriv(pPixmap);
-RegionPtr  pending_damage = NULL;
-BoxRec extents;
-intxoff, yoff;
-
-if (pExaPixmap-pDamage)
-   pending_damage = DamagePendingRegion(pExaPixmap-pDamage);
-
-if (pending_damage) {
-   extents = *REGION_EXTENTS(pScreen, pending_damage);
-
-   if (extents.x1 = extents.x2 || extents.y1 = extents.y2)
-   return;
-
-   depthMask = FbFullMask(pDrawable-depth);
-}
-
-if (!pending_damage || (pGC-planemask  depthMask) != depthMask)
-{
-   ExaCheckImageGlyphBlt(pDrawable, pGC, x, y, nglyph, ppciInit, 
pglyphBase);
-   return;
-}
-
-glyph = NULL;
-switch (pDrawable-bitsPerPixel) {
-case 8:glyph = fbGlyph8; break;
-case 16:glyph = fbGlyph16; break;
-case 24:glyph = fbGlyph24; break;
-case 32:glyph = fbGlyph32; break;
-}
-
-x += pDrawable-x;
-y += pDrawable-y;
-
-exaGetDrawableDeltas(pDrawable, pPixmap, xoff, yoff);
-extents.x1 -= xoff;
-extents.x2 -= xoff;
-extents.y1 -= yoff;
-extents.y2 -= yoff;
-
-exaPrepareAccessReg (pDrawable, EXA_PREPARE_DEST, pending_damage);
-
-if (TERMINALFONT (pGC-font)  !glyph)
-{
-   opaque = TRUE;
-}
-else
-{
-   FbBits fg = fbReplicatePixel (pGC-bgPixel, pDrawable-bitsPerPixel);
-
-   fbSolidBoxClipped (pDrawable,
-  fbGetCompositeClip(pGC),
-  extents.x1,
-  extents.y1,
-  extents.x2,
-  extents.y2,
-  fbAnd (GXcopy, fg, pGC-planemask),
-  fbXor (GXcopy, fg, pGC-planemask));
-
-   opaque = FALSE;
-}
-
-EXA_FALLBACK((to %p (%c)\n, pDrawable, exaDrawableLocation(pDrawable)));
-
-exaPrepareAccessGC (pGC);
-
-fbGetDrawable (pDrawable, dst, dstStride, dstBpp, dstXoff, dstYoff);
-
-for (ppci = ppciInit; nglyph; nglyph--, x += pci-metrics.characterWidth)
-{
-   pci = *ppci++;
-   gWidth = GLYPHWIDTHPIXELS(pci);
-   gHeight = GLYPHHEIGHTPIXELS(pci);
-   gx = x + pci-metrics.leftSideBearing;
-   gy = y - pci-metrics.ascent;
-
-   if (!gWidth || !gHeight || (gx + gWidth) = extents.x1 ||
-   (gy + gHeight) = extents.y1 || gx = extents.x2 ||
-   gy = extents.y2)
-   continue;
-
-   pglyph = FONTGLYPHBITS(pglyphBase, pci);
-
-   if (glyph  gWidth = sizeof (FbStip) * 8 
-   fbGlyphIn (fbGetCompositeClip(pGC), gx, gy, gWidth, gHeight))
-   {
-   (*glyph) (dst + (gy + dstYoff) * dstStride, dstStride, dstBpp,
- (FbStip *) pglyph, pPriv-fg, gx + dstXoff, gHeight);
-   }
-   else
-   {
-   RegionPtr pClip = fbGetCompositeClip(pGC);
-
-   gStride = GLYPHWIDTHBYTESPADDED(pci) / sizeof (FbStip);
-   fbPutXYImage (pDrawable, pClip, pPriv-fg, pPriv-bg, pPriv-pm,
- GXcopy, opaque, gx, gy, gWidth, gHeight,
- (FbStip *) pglyph, gStride, 0);
-   }
-}
-exaFinishAccessGC (pGC);
-exaFinishAccess (pDrawable, EXA_PREPARE_DEST);
-}
-
 const GCOps exaOps = {
 exaFillSpans,
 ExaCheckSetSpans,
@@ -987,7 +854,7 @@ const GCOps exaOps = {
 miPolyText16,
 miImageText8,
 miImageText16,
-exaImageGlyphBlt,
+

Re: xf86-input-evdev: Changes to 'master'

[Peter Hutterer]

On Tue, Feb 03, 2009 at 05:35:49AM -0800, Dan Nicholson wrote:
  applied the patch locally, ran make distcheck and it still fails. Am I doing
  anything wrong?
  AFAICT from a quick peek, ${includedir} isn't expanded. Can you double-check
  this please?
 
 That part worked for me, but it does fail on ChangeLog somehow.
 ${includedir} gets expanded by make eventually. Look at the generated
 Makefile. All the derived directories like bindir are similar unless
 you've explicitly set it from configure. How is it failing for you?

doh. you're right, same here, the changelog is the issue here too.
How about the diff below?
If that's the right thing, just merge it into your patch and re-send the
complete version. (I could do it locally, but I'd like to have the final
version of the patch on the list archives)

diff --git a/Makefile.am b/Makefile.am
index 54814c3..d7a5a65 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -33,6 +33,7 @@ pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA = xorg-evdev.pc
 
 EXTRA_DIST = ChangeLog
+DISTCLEANFILES = ChangeLog
 
 MAINTAINERCLEANFILES=ChangeLog


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] __GLX_MEM_COPY(): no need to check for NULL pointers

[Tomas Carnecky]

warning: the address of ‘XXX’ will always evaluate as ‘true’

This macro is exclusively used on pointers that are guaranteed
to be valid. Either because the variable is on the stack, or
the pointer is already being dereferenced earlier so by the time
the macro is used, we can rely on it being valid.

Signed-off-by: Tomas Carnecky t...@dbservice.com
---

Thanks for the review.

Btw, the code in dmx/glxProxy/ also doesn't have this check.
grep -E '(__GLX_MEM_COPY|__GLX_GET_DOUBLE)' -r glx/ hw/dmx/glxProxy/

 glx/unpack.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/glx/unpack.h b/glx/unpack.h
index a1dd17d..675d8cc 100644
--- a/glx/unpack.h
+++ b/glx/unpack.h
@@ -47,7 +47,7 @@
 ** Fetch a double from potentially unaligned memory.
 */
 #ifdef __GLX_ALIGN64
-#define __GLX_MEM_COPY(dst,src,n)  if (src  dst) memcpy(dst,src,n)
+#define __GLX_MEM_COPY(dst,src,n)  memcpy(dst,src,n)
 #define __GLX_GET_DOUBLE(dst,src)  __GLX_MEM_COPY(dst,src,8)
 #else
 #define __GLX_GET_DOUBLE(dst,src)  (dst) = *((GLdouble*)(src))
-- 
1.6.1.2


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 8/9] fb: split off a few functions into a seperate file and enhance them slightly.

[Maarten Maathuis]

- Compatibility wrappers, if deemed neccesary will come later.
---
 fb/Makefile.am  |3 +-
 fb/fb.h |   37 +-
 fb/fb24_32.c|4 +-
 fb/fbcopy.c |  342 ++-
 fb/fbcopy_helpers.c |  367 +++
 fb/fbcopy_helpers.h |   52 +++
 fb/fboverlay.c  |1 +
 fb/fbwindow.c   |5 +-
 8 files changed, 448 insertions(+), 363 deletions(-)
 create mode 100644 fb/fbcopy_helpers.c
 create mode 100644 fb/fbcopy_helpers.h

diff --git a/fb/Makefile.am b/fb/Makefile.am
index 64e49f3..cfd9364 100644
--- a/fb/Makefile.am
+++ b/fb/Makefile.am
@@ -7,7 +7,7 @@ INCLUDES = \
 AM_CFLAGS = $(DIX_CFLAGS)
 
 if XORG
-sdk_HEADERS = fb.h fbrop.h fboverlay.h wfbrename.h fbpict.h
+sdk_HEADERS = fb.h fbrop.h fboverlay.h wfbrename.h fbpict.h fbcopy_helpers.h
 endif
 
 libfb_la_CFLAGS = $(AM_CFLAGS)
@@ -24,6 +24,7 @@ libfb_la_SOURCES =\
fbbits.h\
fbblt.c \
fbbltone.c  \
+   fbcopy_helpers.c\
fbcopy.c\
fbfill.c\
fbfillrect.c\
diff --git a/fb/fb.h b/fb/fb.h
index 8384315..b0898b0 100644
--- a/fb/fb.h
+++ b/fb/fb.h
@@ -788,7 +788,7 @@ fb24_32GetImage (DrawablePtr pDrawable,
 unsigned long   planeMask,
 char*d);
 
-extern _X_EXPORT void
+extern _X_EXPORT Bool
 fb24_32CopyMtoN (DrawablePtr pSrcDrawable,
 DrawablePtr pDstDrawable,
 GCPtr   pGC,
@@ -1306,7 +1306,7 @@ fbInitVisuals (VisualPtr*visualp,
  * fbcopy.c
  */
 
-typedef void   (*fbCopyProc) (DrawablePtr  pSrcDrawable,
+typedef Bool   (*fbCopyProc) (DrawablePtr  pSrcDrawable,
   DrawablePtr  pDstDrawable,
   GCPtrpGC,
   BoxPtr   pDstBox,
@@ -1318,7 +1318,7 @@ typedef void  (*fbCopyProc) (DrawablePtr  
pSrcDrawable,
   Pixelbitplane,
   void *closure);
 
-extern _X_EXPORT void
+extern _X_EXPORT Bool
 fbCopyNtoN (DrawablePtrpSrcDrawable,
DrawablePtr pDstDrawable,
GCPtr   pGC,
@@ -1331,7 +1331,7 @@ fbCopyNtoN (DrawablePtr   pSrcDrawable,
Pixel   bitplane,
void*closure);
 
-extern _X_EXPORT void
+extern _X_EXPORT Bool
 fbCopy1toN (DrawablePtrpSrcDrawable,
DrawablePtr pDstDrawable,
GCPtr   pGC,
@@ -1344,7 +1344,7 @@ fbCopy1toN (DrawablePtr   pSrcDrawable,
Pixel   bitplane,
void*closure);
 
-extern _X_EXPORT void
+extern _X_EXPORT Bool
 fbCopyNto1 (DrawablePtrpSrcDrawable,
DrawablePtr pDstDrawable,
GCPtr   pGC,
@@ -1357,31 +1357,6 @@ fbCopyNto1 (DrawablePtr  pSrcDrawable,
Pixel   bitplane,
void*closure);
 
-extern _X_EXPORT void
-fbCopyRegion (DrawablePtr   pSrcDrawable,
- DrawablePtr   pDstDrawable,
- GCPtr pGC,
- RegionPtr pDstRegion,
- int   dx,
- int   dy,
- fbCopyProccopyProc,
- Pixel bitPlane,
- void  *closure);
-
-extern _X_EXPORT RegionPtr
-fbDoCopy (DrawablePtr  pSrcDrawable,
- DrawablePtr   pDstDrawable,
- GCPtr pGC,
- int   xIn, 
- int   yIn,
- int   widthSrc, 
- int   heightSrc,
- int   xOut, 
- int   yOut,
- fbCopyProccopyProc,
- Pixel bitplane,
- void  *closure);
- 
 extern _X_EXPORT RegionPtr
 fbCopyArea (DrawablePtrpSrcDrawable,
DrawablePtr pDstDrawable,
@@ -2036,7 +2011,7 @@ fbPositionWindow(WindowPtr pWin, int x, int y);
 extern _X_EXPORT Bool
 fbUnmapWindow(WindowPtr pWindow);
 
-extern _X_EXPORT void
+extern _X_EXPORT Bool
 fbCopyWindowProc (DrawablePtr  pSrcDrawable,
  DrawablePtr   pDstDrawable,
  GCPtr pGC,
diff --git a/fb/fb24_32.c b/fb/fb24_32.c
index 1ebd598..952b9ff 100644
--- a/fb/fb24_32.c
+++ b/fb/fb24_32.c
@@ -472,7 +472,7 @@ fb24_32GetImage (DrawablePtr pDrawable,
 fbFinishAccess (pDrawable);
 }
 
-void
+Bool
 fb24_32CopyMtoN (DrawablePtr pSrcDrawable,
 DrawablePtr pDstDrawable,
 GCPtr   pGC,
@@ -529,6 +529,8 @@ fb24_32CopyMtoN (DrawablePtr pSrcDrawable,
 
 fbFinishAccess (pSrcDrawable);
 fbFinishAccess (pDstDrawable);
+
+return TRUE;
 }
 
 PixmapPtr
diff --git a/fb/fbcopy.c b/fb/fbcopy.c
index b8b0b6a..2f430b7 100644
--- a/fb/fbcopy.c
+++ b/fb/fbcopy.c
@@ -27,8 +27,9 @@
 #include stdlib.h
 
 #include fb.h
+#include fbcopy_helpers.h
 
-void
+Bool
 fbCopyNtoN (DrawablePtrpSrcDrawable,
DrawablePtr pDstDrawable,

Re: [PATCH] dix: die if we can't activate or init the VCP/VCK.

[Dan Nicholson]

On Tue, Feb 3, 2009 at 4:30 PM, Peter Hutterer peter.hutte...@who-t.net wrote:
 If we have a busted xkb setup, the XKB initialization on the core devices
 fails and leaves us with dev-key-xkbInfo == NULL. This in turn causes
 segfaults lateron.

 Return BadValue when the XKB configuration for a master device failed, and if
 that happens for the VCP/VCK, die semi-gracefully.

Seems reasonable to me. I'd much rather die early than scratch my head
on some later crash. Would it also be a good idea to return BadValue
from CorePointerProc when InitPointerDeviceStruct fails? I don't know
what you'd put in the log in that situation, though.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] Fix warning: XXX defined but not used

[Tomas Carnecky]

generic.c:80: warning: ‘read_legacy_video_BIOS’ defined but not used

Signed-off-by: Tomas Carnecky t...@dbservice.com
---
 hw/xfree86/int10/generic.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/hw/xfree86/int10/generic.c b/hw/xfree86/int10/generic.c
index 4808108..9d39e99 100644
--- a/hw/xfree86/int10/generic.c
+++ b/hw/xfree86/int10/generic.c
@@ -75,6 +75,7 @@ static void *sysMem = NULL;
  * etc.).  How do we know that \c pci_device_read_rom will return the
  * legacy VGA BIOS image?
  */
+#ifndef _PC
 static int
 read_legacy_video_BIOS(struct pci_device *dev, unsigned char *Buf)
 {
@@ -114,6 +115,7 @@ read_legacy_video_BIOS(struct pci_device *dev, unsigned 
char *Buf)
 
 return Len;
 }
+#endif /* _PC */
 
 
 xf86Int10InfoPtr
-- 
1.6.1.2


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xf86-input-evdev: Changes to 'master'

[Dan Nicholson]

On Tue, Feb 3, 2009 at 4:39 PM, Peter Hutterer peter.hutte...@who-t.net wrote:
 On Tue, Feb 03, 2009 at 05:35:49AM -0800, Dan Nicholson wrote:
  applied the patch locally, ran make distcheck and it still fails. Am I 
  doing
  anything wrong?
  AFAICT from a quick peek, ${includedir} isn't expanded. Can you 
  double-check
  this please?

 That part worked for me, but it does fail on ChangeLog somehow.
 ${includedir} gets expanded by make eventually. Look at the generated
 Makefile. All the derived directories like bindir are similar unless
 you've explicitly set it from configure. How is it failing for you?

 doh. you're right, same here, the changelog is the issue here too.
 How about the diff below?
 If that's the right thing, just merge it into your patch and re-send the
 complete version. (I could do it locally, but I'd like to have the final
 version of the patch on the list archives)

 diff --git a/Makefile.am b/Makefile.am
 index 54814c3..d7a5a65 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -33,6 +33,7 @@ pkgconfigdir = $(libdir)/pkgconfig
  pkgconfig_DATA = xorg-evdev.pc

  EXTRA_DIST = ChangeLog
 +DISTCLEANFILES = ChangeLog

  MAINTAINERCLEANFILES=ChangeLog

Actually, I updated my macros, and now it's working.

http://cgit.freedesktop.org/xorg/util/macros/commit/?id=55e8d740881ef622376440819119641e67aeb285

I don't think we want ChangeLog in DISTCLEANFILES because then a user
with the tarball will remove it on distclean. Not the end of the
world, but it breaks the distclean notion of get me back to the clean
dist state.

Does that work for you?

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 6/9] exa: wrap the remainder of exa_unaccel.c

[Maarten Maathuis]

---
 exa/exa_unaccel.c |   30 +++---
 1 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/exa/exa_unaccel.c b/exa/exa_unaccel.c
index d56f589..a521497 100644
--- a/exa/exa_unaccel.c
+++ b/exa/exa_unaccel.c
@@ -290,9 +290,14 @@ ExaCheckGetSpans (DrawablePtr pDrawable,
 int nspans,
 char *pdstStart)
 {
+ScreenPtr pScreen = pDrawable-pScreen;
+ExaScreenPriv(pScreen);
+
 EXA_FALLBACK((from %p (%c)\n, pDrawable, 
exaDrawableLocation(pDrawable)));
 exaPrepareAccess (pDrawable, EXA_PREPARE_SRC);
-fbGetSpans (pDrawable, wMax, ppt, pwidth, nspans, pdstStart);
+swap(pExaScr, pScreen, GetSpans);
+pScreen-GetSpans (pDrawable, wMax, ppt, pwidth, nspans, pdstStart);
+swap(pExaScr, pScreen, GetSpans);
 exaFinishAccess (pDrawable, EXA_PREPARE_SRC);
 }
 
@@ -310,6 +315,11 @@ ExaCheckComposite (CARD8  op,
CARD16 width,
CARD16 height)
 {
+ScreenPtr pScreen = pDst-pDrawable-pScreen;
+#ifdef RENDER
+PictureScreenPtr   ps = GetPictureScreen(pScreen);
+#endif /* RENDER */
+ExaScreenPriv(pScreen);
 RegionRec region;
 int xoff, yoff;
 
@@ -338,7 +348,9 @@ ExaCheckComposite (CARD8  op,
exaPrepareAccess (pSrc-pDrawable, EXA_PREPARE_SRC);
 if (pMask  pMask-pDrawable != NULL)
exaPrepareAccess (pMask-pDrawable, EXA_PREPARE_MASK);
-fbComposite (op,
+#ifdef RENDER
+swap(pExaScr, ps, Composite);
+ps-Composite (op,
  pSrc,
  pMask,
  pDst,
@@ -350,6 +362,8 @@ ExaCheckComposite (CARD8  op,
  yDst,
  width,
  height);
+swap(pExaScr, ps, Composite);
+#endif /* RENDER */
 if (pMask  pMask-pDrawable != NULL)
exaFinishAccess (pMask-pDrawable, EXA_PREPARE_MASK);
 if (pSrc-pDrawable != NULL)
@@ -366,10 +380,20 @@ ExaCheckAddTraps (PicturePtr  pPicture,
  int   ntrap,
  xTrap *traps)
 {
+ScreenPtr pScreen = pPicture-pDrawable-pScreen;
+#ifdef RENDER
+PictureScreenPtr   ps = GetPictureScreen(pScreen);
+#endif /* RENDER */
+ExaScreenPriv(pScreen);
+
 EXA_FALLBACK((to pict %p (%c)\n,
  exaDrawableLocation(pPicture-pDrawable)));
 exaPrepareAccess(pPicture-pDrawable, EXA_PREPARE_DEST);
-fbAddTraps (pPicture, x_off, y_off, ntrap, traps);
+#ifdef RENDER
+swap(pExaScr, ps, AddTraps);
+ps-AddTraps (pPicture, x_off, y_off, ntrap, traps);
+swap(pExaScr, ps, AddTraps);
+#endif /* RENDER */
 exaFinishAccess(pPicture-pDrawable, EXA_PREPARE_DEST);
 }
 
-- 
1.6.1.1

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] dix: die if we can't activate or init the VCP/VCK.

[Peter Hutterer]

On Tue, Feb 03, 2009 at 04:46:05PM -0800, Dan Nicholson wrote:
 On Tue, Feb 3, 2009 at 4:30 PM, Peter Hutterer peter.hutte...@who-t.net 
 wrote:
  If we have a busted xkb setup, the XKB initialization on the core devices
  fails and leaves us with dev-key-xkbInfo == NULL. This in turn causes
  segfaults lateron.
 
  Return BadValue when the XKB configuration for a master device failed, and 
  if
  that happens for the VCP/VCK, die semi-gracefully.
 
 Seems reasonable to me. I'd much rather die early than scratch my head
 on some later crash. Would it also be a good idea to return BadValue
 from CorePointerProc when InitPointerDeviceStruct fails? I don't know
 what you'd put in the log in that situation, though.

IPDS seems to only fail if we run out of memory. What about adding hunk 2?

Cheers,
  Peter

From 29b2848cecf1ccde8fba7d7b1bfafa03873753d8 Mon Sep 17 00:00:00 2001
From: Peter Hutterer peter.hutte...@who-t.net
Date: Wed, 4 Feb 2009 10:11:13 +1000
Subject: [PATCH] dix: die if we can't activate or init the VCP/VCK.

If we have a busted xkb setup, the XKB initialization on the core devices
fails and leaves us with dev-key-xkbInfo == NULL. This in turn causes
segfaults lateron.

Return BadValue when the XKB configuration for a master device failed, and if
that happens for the VCP/VCK, die semi-gracefully.
The VCP init can only fail on OOM.

Reported by Aaron Plattner.

Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
 dix/devices.c |   28 +++-
 1 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/dix/devices.c b/dix/devices.c
index 6578229..f301d98 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -488,8 +488,13 @@ CoreKeyboardProc(DeviceIntPtr pDev, int what)
 switch (what) {
 case DEVICE_INIT:
 XkbGetRulesDflts(rmlvo);
-InitKeyboardDeviceStruct(pDev, rmlvo, CoreKeyboardBell,
- CoreKeyboardCtl);
+if (!InitKeyboardDeviceStruct(pDev, rmlvo, CoreKeyboardBell,
+  CoreKeyboardCtl))
+{
+ErrorF(Keyboard initialization failed. This could be a missing 
+   or incorrect setup of xkeyboard-config.\n);
+return BadValue;
+}
 return Success;
 
 case DEVICE_ON:
@@ -519,9 +524,13 @@ CorePointerProc(DeviceIntPtr pDev, int what)
 case DEVICE_INIT:
 for (i = 1; i = 32; i++)
 map[i] = i;
-InitPointerDeviceStruct((DevicePtr)pDev, map, 32,
+if (!InitPointerDeviceStruct((DevicePtr)pDev, map, 32,
 (PtrCtrlProcPtr)NoopDDA,
-GetMotionHistorySize(), 2);
+GetMotionHistorySize(), 2))
+{
+ErrorF(Could not initialize device '%s'. OOM\n, pDev-name);
+return BadAlloc; /* IPDS only fails on allocs */
+}
 pDev-valuator-axisVal[0] = screenInfo.screens[0]-width / 2;
 pDev-last.valuators[0] = pDev-valuator-axisVal[0];
 pDev-valuator-axisVal[1] = screenInfo.screens[0]-height / 2;
@@ -554,11 +563,12 @@ InitCoreDevices(void)
   inputInfo.keyboard) != Success)
 FatalError(Failed to allocate core devices);
 
-ActivateDevice(inputInfo.pointer);
-ActivateDevice(inputInfo.keyboard);
-EnableDevice(inputInfo.pointer);
-EnableDevice(inputInfo.keyboard);
-
+if (ActivateDevice(inputInfo.pointer) != Success ||
+ActivateDevice(inputInfo.keyboard) != Success)
+FatalError(Failed to activate core devices.);
+if (!EnableDevice(inputInfo.pointer) ||
+!EnableDevice(inputInfo.keyboard))
+FatalError(Failed to enable core devices.);
 }
 
 /**
-- 
1.6.0.6


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] Make gcc happy: correct third argument of CopyGetMasterEvent()

[Tomas Carnecky]

Signed-off-by: Tomas Carnecky t...@dbservice.com
---
 xkb/ddxDevBtn.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xkb/ddxDevBtn.c b/xkb/ddxDevBtn.c
index 03fb440..aad9661 100644
--- a/xkb/ddxDevBtn.c
+++ b/xkb/ddxDevBtn.c
@@ -116,7 +116,7 @@ DeviceIntPtrmaster = NULL;
 if (!IsPointerDevice(master))
 master = GetPairedDevice(dev-u.master);
 
-CopyGetMasterEvent(master, dev, events, masterEvents, count);
+CopyGetMasterEvent(master, dev, events, masterEvents, count);
 }
 
 (*dev-public.processInputProc)((xEventPtr)btn, dev, count);
-- 
1.6.1.2


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Fixing compiler warnings

[Peter Hutterer]

On Mon, Feb 02, 2009 at 11:02:57PM +0100, Tomas Carnecky wrote:
 I've been trying to fix the compiler warnings that gcc generates when 
 compiling the xserver source. 

Pushed all minus the two I commented on, and the sdksyms.sh patch. I don't
know whether that's the right thing to do, so I left it.
Thanks for the patches.

 I've been able to fix quite a few, but 
 there are still some left, which I don't know how to resolve. I have 14 
 patches for the xserver and two for libxtrans. I can post them either 
 individually or give you a link to my public repo from which you can 
 fetch, or give you a link to cgit so you can look at the commits with a 
 web browser. All patches except one of the libxtrans patches are just a 
 couple lines. But one is huge (94KB) because it touches much of the 
 libxtrans code.
 
 However, there are a few warnings I was not able to fix, and some I 
 probably won't be fixing (the ones that come from fb/ -- a scary place 
 which is using lots of macros and other obfuscation techniques). That 
 leaves me with a handful of different types of warnings which should be 
 easy to fix, once I know what the preferred approach is. So let's start:
 
 --
 bigreq.c:46: warning: no previous prototype for ‘BigReqExtensionInit’
 sync.c:2124: warning: no previous prototype for ‘SyncExtensionInit’
 xcmisc.c:59: warning: no previous prototype for ‘XCMiscExtensionInit’
 
 These three extensions are the only ones that have no previous 
 prototype. It seems as the other extensions have their prototype from 
 hw/xfree86/dixmods/extmod/modinit.h. It seems a bit strange that Xext/ 
 modules include a file from hw/. But I'm not that familiar with the 
 dependencies so I'll leave it up to you to decide what's to be done here.

our header files are a bit of a mess, so if something looks really stupid,
chances are it might just be that.

 --
 glapitemp.h:1884: warning: ‘NoOp_dispatch_stub_339’ defined but not used
 (repeated many times for different stubs)
 
 The file seems to have a mechanism to silence the compiler:
 /*
   * This is just used to silence compiler warnings.
   * We list the functions which are not otherwise used.
   */
 
 Maybe the gl_apitemp.py scripts needs to be updated and the file 
 regenerated?
 
 --
 warning: cast to pointer from integer of different size
 warning: cast from function call of type ‘pointer’ to non-matching type 
 ‘long unsigned int’
 
 This is because the code casts integers to pointers and back. Most of 
 the time the code just wants to save an int in the private data, and 
 uses something along these lines:
 
int i;
dixSetPrivate(devPrivates, myKey, (pointer) i);
i = dixGetPrivate(devPrivates, myKey);
 
 Should the code use (u)intptr_t in these cases?
 
 In three cases the warning is about code in hw/xfree86/dri/dri.c casting 
 a void pointer to drm_handle_t which is 'unsigned int'.
 
 --
 sdksyms.c:1056: warning: initialization discards qualifiers from pointer 
 target type
 
 It seems because isItTimeToYield is declared volatile? Is it OK to 
 explicitly cast that symbol to 'void *'?
 
 --
 Finally some warnings about deprecated functions. I don't think there's 
 anything that can be done with it except eventually removing the 
 functions, right?
 
 --
 One warning in xf86Bus.c:x_isSubsetOf() which I reported in an earlier 
 mail. Maybe nobody cares about the code anymore. It hasn't been touched 
 since the initial import.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] dix: die if we can't activate or init the VCP/VCK.

[Daniel Stone]

On Wed, Feb 04, 2009 at 10:51:21AM +1000, Peter Hutterer wrote:
 From 29b2848cecf1ccde8fba7d7b1bfafa03873753d8 Mon Sep 17 00:00:00 2001
 From: Peter Hutterer peter.hutte...@who-t.net
 Date: Wed, 4 Feb 2009 10:11:13 +1000
 Subject: [PATCH] dix: die if we can't activate or init the VCP/VCK.
 
 If we have a busted xkb setup, the XKB initialization on the core devices
 fails and leaves us with dev-key-xkbInfo == NULL. This in turn causes
 segfaults lateron.
 
 Return BadValue when the XKB configuration for a master device failed, and if
 that happens for the VCP/VCK, die semi-gracefully.
 The VCP init can only fail on OOM.
 
 Reported by Aaron Plattner.
 
 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net

Acked-by: Daniel Stone dan...@fooishbar.org


signature.asc
Description: Digital signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xf86-input-evdev: Changes to 'master'

[Peter Hutterer]

On Tue, Feb 03, 2009 at 04:50:17PM -0800, Dan Nicholson wrote:
 On Tue, Feb 3, 2009 at 4:39 PM, Peter Hutterer peter.hutte...@who-t.net 
 wrote:
  On Tue, Feb 03, 2009 at 05:35:49AM -0800, Dan Nicholson wrote:
   applied the patch locally, ran make distcheck and it still fails. Am I 
   doing
   anything wrong?
   AFAICT from a quick peek, ${includedir} isn't expanded. Can you 
   double-check
   this please?
 
  That part worked for me, but it does fail on ChangeLog somehow.
  ${includedir} gets expanded by make eventually. Look at the generated
  Makefile. All the derived directories like bindir are similar unless
  you've explicitly set it from configure. How is it failing for you?
 
  doh. you're right, same here, the changelog is the issue here too.
  How about the diff below?
  If that's the right thing, just merge it into your patch and re-send the
  complete version. (I could do it locally, but I'd like to have the final
  version of the patch on the list archives)
 
  diff --git a/Makefile.am b/Makefile.am
  index 54814c3..d7a5a65 100644
  --- a/Makefile.am
  +++ b/Makefile.am
  @@ -33,6 +33,7 @@ pkgconfigdir = $(libdir)/pkgconfig
   pkgconfig_DATA = xorg-evdev.pc
 
   EXTRA_DIST = ChangeLog
  +DISTCLEANFILES = ChangeLog
 
   MAINTAINERCLEANFILES=ChangeLog
 
 Actually, I updated my macros, and now it's working.
 
 http://cgit.freedesktop.org/xorg/util/macros/commit/?id=55e8d740881ef622376440819119641e67aeb285
 
 I don't think we want ChangeLog in DISTCLEANFILES because then a user
 with the tarball will remove it on distclean. Not the end of the
 world, but it breaks the distclean notion of get me back to the clean
 dist state.
 
 Does that work for you?

yeah, updating works, thanks. Should we make macros 1.2.1 a requirement then?

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] dix: die if we can't activate or init the VCP/VCK.

[Dan Nicholson]

On Tue, Feb 3, 2009 at 4:51 PM, Peter Hutterer peter.hutte...@who-t.net wrote:
 On Tue, Feb 03, 2009 at 04:46:05PM -0800, Dan Nicholson wrote:
 On Tue, Feb 3, 2009 at 4:30 PM, Peter Hutterer peter.hutte...@who-t.net 
 wrote:
  If we have a busted xkb setup, the XKB initialization on the core devices
  fails and leaves us with dev-key-xkbInfo == NULL. This in turn causes
  segfaults lateron.
 
  Return BadValue when the XKB configuration for a master device failed, and 
  if
  that happens for the VCP/VCK, die semi-gracefully.

 Seems reasonable to me. I'd much rather die early than scratch my head
 on some later crash. Would it also be a good idea to return BadValue
 from CorePointerProc when InitPointerDeviceStruct fails? I don't know
 what you'd put in the log in that situation, though.

 IPDS seems to only fail if we run out of memory. What about adding hunk 2?

Yeah, looks like it.

Acked-by: Dan Nicholson dbn.li...@gmail.com

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xf86-input-evdev: Changes to 'master'

[Dan Nicholson]

On Tue, Feb 3, 2009 at 5:00 PM, Peter Hutterer peter.hutte...@who-t.net wrote:
 On Tue, Feb 03, 2009 at 04:50:17PM -0800, Dan Nicholson wrote:
 On Tue, Feb 3, 2009 at 4:39 PM, Peter Hutterer peter.hutte...@who-t.net 
 wrote:
  On Tue, Feb 03, 2009 at 05:35:49AM -0800, Dan Nicholson wrote:
   applied the patch locally, ran make distcheck and it still fails. Am I 
   doing
   anything wrong?
   AFAICT from a quick peek, ${includedir} isn't expanded. Can you 
   double-check
   this please?
 
  That part worked for me, but it does fail on ChangeLog somehow.
  ${includedir} gets expanded by make eventually. Look at the generated
  Makefile. All the derived directories like bindir are similar unless
  you've explicitly set it from configure. How is it failing for you?
 
  doh. you're right, same here, the changelog is the issue here too.
  How about the diff below?
  If that's the right thing, just merge it into your patch and re-send the
  complete version. (I could do it locally, but I'd like to have the final
  version of the patch on the list archives)
 
  diff --git a/Makefile.am b/Makefile.am
  index 54814c3..d7a5a65 100644
  --- a/Makefile.am
  +++ b/Makefile.am
  @@ -33,6 +33,7 @@ pkgconfigdir = $(libdir)/pkgconfig
   pkgconfig_DATA = xorg-evdev.pc
 
   EXTRA_DIST = ChangeLog
  +DISTCLEANFILES = ChangeLog
 
   MAINTAINERCLEANFILES=ChangeLog

 Actually, I updated my macros, and now it's working.

 http://cgit.freedesktop.org/xorg/util/macros/commit/?id=55e8d740881ef622376440819119641e67aeb285

 I don't think we want ChangeLog in DISTCLEANFILES because then a user
 with the tarball will remove it on distclean. Not the end of the
 world, but it breaks the distclean notion of get me back to the clean
 dist state.

 Does that work for you?

 yeah, updating works, thanks. Should we make macros 1.2.1 a requirement then?

Yeah, there should probably be a mass push to 1.2.1 for any packages
(all of them, I think) that are using XORG_CHANGELOG. Sounds fun.

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] dix: die if we can't activate or init the VCP/VCK.

[Aaron Plattner]

On Tue, Feb 03, 2009 at 04:30:45PM -0800, Peter Hutterer wrote:
 If we have a busted xkb setup, the XKB initialization on the core devices
 fails and leaves us with dev-key-xkbInfo == NULL. This in turn causes
 segfaults lateron.
 
 Return BadValue when the XKB configuration for a master device failed, and if
 that happens for the VCP/VCK, die semi-gracefully.
 
 Reported by Aaron Plattner.
 
 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net

Looks good to me:

(EE) XKB: Couldn't open rules file /X/share/X11/xkb/rules/evdev
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup 
of xkeyboard-config.

Fatal server error:
Failed to activate core devices.

Signed-off-by: Aaron Plattner aplatt...@nvidia.com

[resending with fixed To: header]
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] Add a prototype for CopyGetMasterEvent()

[Paulo César Pereira de Andrade]

Peter Hutterer wrote:
 On Wed, Feb 04, 2009 at 12:03:12AM +0100, Tomas Carnecky wrote:
 This function is defined in mi/mieq.c and used in xkb/ddxDevBtn.c,
 hence it needs a prototype.

 Signed-off-by: Tomas Carnecky t...@dbservice.com
 ---
  include/input.h |8 
  1 files changed, 8 insertions(+), 0 deletions(-)

 diff --git a/include/input.h b/include/input.h
 index 3b7a173..a91e7e9 100644
 --- a/include/input.h
 +++ b/include/input.h
 @@ -474,6 +474,14 @@ extern _X_EXPORT int AllocMasterDevice(ClientPtr
 client,
  extern _X_EXPORT void DeepCopyDeviceClasses(DeviceIntPtr from,
DeviceIntPtr to);

 +extern _X_EXPORT void CopyGetMasterEvent(
 +DeviceIntPtr mdev,
 +DeviceIntPtr sdev,
 +xEvent* original,
 +EventListPtr master,
 +int count
 +);
 +

 _X_INTERNAL is the better approach here. CGME should not be visible to
 anyone
 but the server itself.

  IMO _X_INTERNAL should be used with extreme care, as it may cause
erroneous behavior if not properly used, while _X_HIDDEN always does
what one would expect, but feel free to tell me otherwise :-) (probably
a _X_PROTECTED would be more appropriate); _X_INTERNAL is also just
__hidden attribute for Sun CC. The problem is that a function with
attribute internal cannot be called via a function pointer by another
shared object.

  Also note that in the current way sdksyms.sh parses cpp output,
it will take the address of that function, because the header is
in the build tree, and the line starts with extern (currently one
could cheat by just adding a space before extern). So, the proper
solution should be to declare the symbol in a non sdk header, where
it would not be required to use any _X_FOO attribute.

  I plan to convert the cpp output parser to generate a linker
script, what should be significantly more reliable, but the first
approach was to automatically generate what was once a series of
hand written and outdated files (but referencing enough symbols to
prevent the linker from finding unreachable symbols, that would
only be reachable from external modules).

 Cheers,
   Peter

Paulo

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

libpciaccess MTRR splitting

[Francisco Jerez]

Hi.

Since I switched to libpciaccess, I've been seeing errors like:

 error setting MTRR (base = 0x1420, size = 0x0080, type = 1) Invalid 
 argument (22)

It's because the GPU I'm using (a siliconmotion SM720) has a register
area at the beginning of the PCI BAR which shouldn't be set to WC, and
the remaining memory (the actual framebuffer) isn't aligned at a size
multiple.

I've been running a modified version of libpciaccess (diff attached)
that splits the memory range on properly aligned chunks before setting
the MTRRs.

If it turns out to be a reasonable approach, I'm willing to document
it more thoroughly and format it for git-am.

I've only implemented it for the linux_sysfs backend, but the logic at
pci_mapping_split is somewhat generic and another source file might be
better suited for it.

diff --git a/src/linux_sysfs.c b/src/linux_sysfs.c
index 8c3cf67..b99cb31 100644
--- a/src/linux_sysfs.c
+++ b/src/linux_sysfs.c
@@ -95,6 +95,16 @@ static const struct pci_system_methods linux_sysfs_methods = {
 
 static int populate_entries(struct pci_system * pci_sys);
 
+#ifdef HAVE_MTRR
+static int pci_device_linux_sysfs_set_mtrr(struct pci_device_mapping *map);
+
+static int pci_device_linux_sysfs_unset_mtrr(struct pci_device_mapping *map);
+
+#endif
+
+static int pci_mapping_split(struct pci_device_mapping *map,
+			  int (*proc)(struct pci_device_mapping*));
+
 
 /**
  * Attempt to access PCI subsystem using Linux's sysfs interface.
@@ -547,13 +557,6 @@ pci_device_linux_sysfs_map_range(struct pci_device *dev,
 const int open_flags = ((map-flags  PCI_DEV_MAP_FLAG_WRITABLE) != 0) 
 ? O_RDWR : O_RDONLY;
 const off_t offset = map-base - dev-regions[map-region].base_addr;
-#ifdef HAVE_MTRR
-struct mtrr_sentry sentry = {
-	.base = map-base,
-.size = map-size,
-	.type = MTRR_TYPE_UNCACHABLE
-};
-#endif
 
 /* For WC mappings, try sysfs resourceN_wc file first */
 if ((map-flags  PCI_DEV_MAP_FLAG_WRITE_COMBINE) 
@@ -582,22 +585,12 @@ pci_device_linux_sysfs_map_range(struct pci_device *dev,
 }
 
 #ifdef HAVE_MTRR
-if ((map-flags  PCI_DEV_MAP_FLAG_CACHABLE) != 0) {
-sentry.type = MTRR_TYPE_WRBACK;
-} else if ((map-flags  PCI_DEV_MAP_FLAG_WRITE_COMBINE) != 0) {
-sentry.type = MTRR_TYPE_WRCOMB;
-}
+if (pci_sys-mtrr_fd != -1 
+	(map-flags  (PCI_DEV_MAP_FLAG_CACHABLE |
+		   PCI_DEV_MAP_FLAG_WRITE_COMBINE))){
+
+	(void) pci_mapping_split(map, pci_device_linux_sysfs_set_mtrr);
 
-if (pci_sys-mtrr_fd != -1  sentry.type != MTRR_TYPE_UNCACHABLE) {
-	if (ioctl(pci_sys-mtrr_fd, MTRRIOC_ADD_ENTRY, sentry)  0) {
-	/* FIXME: Should we report an error in this case?
-	 */
-	fprintf(stderr, error setting MTRR 
-		(base = 0x%08lx, size = 0x%08x, type = %u) %s (%d)\n,
-		sentry.base, sentry.size, sentry.type,
-		strerror(errno), errno);
-/*err = errno;*/
-	}
 	/* KLUDGE ALERT -- rewrite the PTEs to turn off the CD and WT bits */
 	mprotect (map-memory, map-size, PROT_NONE);
 	err = mprotect (map-memory, map-size, PROT_READ|PROT_WRITE);
@@ -644,35 +637,17 @@ pci_device_linux_sysfs_unmap_range(struct pci_device *dev,
    struct pci_device_mapping *map)
 {
 int err = 0;
-#ifdef HAVE_MTRR
-struct mtrr_sentry sentry = {
-	.base = map-base,
-.size = map-size,
-	.type = MTRR_TYPE_UNCACHABLE
-};
-#endif
 
 err = pci_device_generic_unmap_range (dev, map);
 if (err)
 	return err;
 
 #ifdef HAVE_MTRR
-if ((map-flags  PCI_DEV_MAP_FLAG_CACHABLE) != 0) {
-sentry.type = MTRR_TYPE_WRBACK;
-} else if ((map-flags  PCI_DEV_MAP_FLAG_WRITE_COMBINE) != 0) {
-sentry.type = MTRR_TYPE_WRCOMB;
-}
+if (pci_sys-mtrr_fd != -1 
+	(map-flags  (PCI_DEV_MAP_FLAG_CACHABLE |
+		   PCI_DEV_MAP_FLAG_WRITE_COMBINE))){
 
-if (pci_sys-mtrr_fd != -1  sentry.type != MTRR_TYPE_UNCACHABLE) {
-	if (ioctl(pci_sys-mtrr_fd, MTRRIOC_DEL_ENTRY, sentry)  0) {
-	/* FIXME: Should we report an error in this case?
-	 */
-	fprintf(stderr, error setting MTRR 
-		(base = 0x%08lx, size = 0x%08x, type = %u) %s (%d)\n,
-		sentry.base, sentry.size, sentry.type,
-		strerror(errno), errno);
-/*err = errno;*/
-	}
+	(void) pci_mapping_split(map, pci_device_linux_sysfs_unset_mtrr);
 }
 #endif
 
@@ -698,3 +673,83 @@ static void pci_device_linux_sysfs_enable(struct pci_device *dev)
 write( fd, 1, 1 );
 close(fd);
 }
+
+#ifdef HAVE_MTRR
+
+static int
+pci_device_linux_sysfs_set_mtrr(struct pci_device_mapping *map)
+{
+struct mtrr_sentry sentry = {
+	.base = map-base,
+.size = map-size,
+	.type = ((map-flags  PCI_DEV_MAP_FLAG_CACHABLE) ? MTRR_TYPE_WRBACK :
+		 (map-flags  PCI_DEV_MAP_FLAG_WRITE_COMBINE) ? MTRR_TYPE_WRCOMB :
+		 MTRR_TYPE_UNCACHABLE)
+};
+
+if (ioctl(pci_sys-mtrr_fd, MTRRIOC_ADD_ENTRY, sentry)  0) {
+	/* FIXME: Should we report an error in this case?
+	 */
+	fprintf(stderr, error setting MTRR 
+		(base = 0x%08lx, size 

Re: [PATCH] Add a prototype for CopyGetMasterEvent()

[Peter Hutterer]

On Wed, Feb 04, 2009 at 12:23:10AM -0200, Paulo César Pereira de Andrade wrote:
 Peter Hutterer wrote:
  On Wed, Feb 04, 2009 at 12:03:12AM +0100, Tomas Carnecky wrote:
  This function is defined in mi/mieq.c and used in xkb/ddxDevBtn.c,
  hence it needs a prototype.
 
  Signed-off-by: Tomas Carnecky t...@dbservice.com
  ---
   include/input.h |8 
   1 files changed, 8 insertions(+), 0 deletions(-)
 
  diff --git a/include/input.h b/include/input.h
  index 3b7a173..a91e7e9 100644
  --- a/include/input.h
  +++ b/include/input.h
  @@ -474,6 +474,14 @@ extern _X_EXPORT int AllocMasterDevice(ClientPtr
  client,
   extern _X_EXPORT void DeepCopyDeviceClasses(DeviceIntPtr from,
 DeviceIntPtr to);
 
  +extern _X_EXPORT void CopyGetMasterEvent(
  +DeviceIntPtr mdev,
  +DeviceIntPtr sdev,
  +xEvent* original,
  +EventListPtr master,
  +int count
  +);
  +
 
  _X_INTERNAL is the better approach here. CGME should not be visible to
  anyone
  but the server itself.
 
   IMO _X_INTERNAL should be used with extreme care, as it may cause
 erroneous behavior if not properly used, while _X_HIDDEN always does
 what one would expect, but feel free to tell me otherwise :-) (probably
 a _X_PROTECTED would be more appropriate); _X_INTERNAL is also just
 __hidden attribute for Sun CC. The problem is that a function with
 attribute internal cannot be called via a function pointer by another
 shared object.

oh. my fault then. I assumed _X_INTERNAL was internal to the server.

   Also note that in the current way sdksyms.sh parses cpp output,
 it will take the address of that function, because the header is
 in the build tree, and the line starts with extern (currently one
 could cheat by just adding a space before extern). So, the proper
 solution should be to declare the symbol in a non sdk header, where
 it would not be required to use any _X_FOO attribute.
 
   I plan to convert the cpp output parser to generate a linker
 script, what should be significantly more reliable, but the first
 approach was to automatically generate what was once a series of
 hand written and outdated files (but referencing enough symbols to
 prevent the linker from finding unreachable symbols, that would
 only be reachable from external modules).

it may be good to clean up the header files first.

I know I mostly added functions where I thought they were appropriate, and
looking back now there's a lot of _X_EXPORT's that shouldn't be there.
The kernel uses a #ifdef __KERNEL__ to hide what's internal only from the
header file. Maybe we should be looking at a similar solution. quite frankly,
the EXPORT, HIDDEN, INTERNAL, etc. is confusing me.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: XtDisplayToApplicationContext fails with Error: Couldn't find per display information

[Glynn Clements]

Tristan Schmelcher wrote:

 Hello all. Sorry if this is not the right place to send this, but I'm
 developing a plugin for Firefox on Linux and I've run up against a
 roadblock. In my plugin I'm being passed a pointer to an X Display struct
 (in NPP_SetWindow, for those of you that know NPAPI) and I'm calling
 XtDisplayToApplicationContext on it to get an app context to use in various
 Xt calls. Now on most systems this works fine--e.g., Ubuntu Dapper 32-bit
 with FF2 and Intrepid 32-bit with FF3 both work flawlessly. However, when I
 build a 64-bit version and try it on Ubuntu Hardy 64-bit with FF3, it
 doesn't work. When it enters XtDisplayToApplicationContext, I get Error:
 Couldn't find per display information on the console and the program exits.
 
 Does anyone know what could be causing this function to fail? I searched the
 web but without luck.

AFAIK, the display must have been registered with Xt via
XtDisplayInitialize(). With a conventional Xt-based application, this
is done by e.g. XtAppInitialize().

Firefox isn't an Xt application, so I'm a bit surprised that it works
at all. However, digging deeper I see that libxul.so uses Xt:

$ nm -D /opt/firefox/libxul.so | fgrep ' U Xt'
 U XtAddEventHandler
 U XtAppCreateShell
 U XtAppPending
 U XtAppProcessEvent
 U XtAppSetFallbackResources
 U XtCreateApplicationContext
 U XtDestroyWidget
 U XtDisplay
 U XtDisplayToApplicationContext
 U XtManageChild
 U XtOpenDisplay
 U XtRealizeWidget
 U XtRegisterDrawable
 U XtRemoveEventHandler
 U XtSetValues
 U XtShellStrings
 U XtStrings
 U XtToolkitInitialize
 U XtUnrealizeWidget
 U XtUnregisterDrawable
 U XtVaCreateWidget
 U XtWindow
 U XtWindowToWidget

XtOpenDisplay() calls XtDisplayInitialize(), so if it's getting the
Display* from there, it should work. If the Display* comes from
elsewhere (e.g. Gtk/Gdk), it probably won't.

-- 
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Current tinderbox regression (xhost)

[Dan Nicholson]

On Tue, Feb 3, 2009 at 7:20 PM, Paulo César Pereira de Andrade
p...@mandriva.com.br wrote:
 Daniel Stone wrote:
 Hi,

  Hi,

   I hope this is not a final decision. And would hope for a
 more formal message, other then a notification in IRC while
 I am marked as away, and due to no response in 30 minutes
 have my commit rights removed.

 Sorry, it wasn't due to no response to Peter's thing, it was in fact
 mostly separate and prompted by a few other things.

  I was somewhat pissed because I was believing I was doing
 the right thing, that would be to not post very trivial patches
 to the list to avoid unnecessary noise. And mainly because it
 was clearly a single person taking a (well, don't know the
 correct english word, lets try) instinctive decision; lifes
 are lost due to these kinds of reactions...
  The other reason I have been pissed for quite some time,
 is that I believe I am being a victim of some misunderstanding
 or something, maybe because I am extremely shy :-) Talk to
 anybody that knows me personally, I talk only the minimum
 necessary :-) And maybe someone thought I am being evil,
 but yes, I am still an advocate of a GPL'ed X Window System

Paulo, I really like your patches and am glad that someone is going
through and doing the janitor work as well as some of the bigger
patches you've done. However, sometimes I wish you would slow down and
send patches to the list if they might cause breakage. I know that's
subjective because it's tough to say whether something is trivial or
not.

Nothing personal. :)

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] Damage re-used shadow scanout buffer using new transforms.

[Keith Packard]

When the shadow scanout buffer can be re-used, the underlying framebuffer
area must be damaged so that the scanout will be repainted. This patch
delays the addition of that damaged area until after the transform in the
crtc has been updated, otherwise the old transform would have been used and
the wrong area repainted.

Signed-off-by: Keith Packard kei...@keithp.com
---
 hw/xfree86/modes/xf86Rotate.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/hw/xfree86/modes/xf86Rotate.c b/hw/xfree86/modes/xf86Rotate.c
index 21b7aff..dcc3ec0 100644
--- a/hw/xfree86/modes/xf86Rotate.c
+++ b/hw/xfree86/modes/xf86Rotate.c
@@ -406,6 +406,7 @@ xf86CrtcRotate (xf86CrtcPtr crtc)
 intnew_width = 0;
 intnew_height = 0;
 RRTransformPtr transform = NULL;
+Bool   damage = FALSE;
 
 if (crtc-transformPresent)
transform = crtc-transform;
@@ -466,7 +467,7 @@ xf86CrtcRotate (xf86CrtcPtr crtc)
else
{
/* mark shadowed area as damaged so it will be repainted */
-   xf86CrtcDamageShadow (crtc);
+   damage = TRUE;
}
 
if (!xf86_config-rotation_damage)
@@ -540,6 +541,9 @@ xf86CrtcRotate (xf86CrtcPtr crtc)
 crtc-bounds.y2 = crtc-mode.VDisplay;
 pixman_f_transform_bounds (f_crtc_to_fb, crtc-bounds);
 
+if (damage)
+xf86CrtcDamageShadow (crtc);
+
 /* All done */
 return TRUE;
 }
-- 
1.5.6.5

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] Handle the combination of panning and crtc transforms

[Keith Packard]

This patch gets the shadow scanout buffer repainted on panning area changes.
It does not, however, track the mouse correctly.

Signed-off-by: Keith Packard kei...@keithp.com
---
 hw/xfree86/modes/xf86Crtc.c |   36 ++--
 1 files changed, 10 insertions(+), 26 deletions(-)

diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index 40352b4..7dbabda 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -306,33 +306,14 @@ xf86CrtcSetModeTransform (xf86CrtcPtr crtc, 
DisplayModePtr mode, Rotation rotati
 } else
crtc-transformPresent = FALSE;
 
-/* Shift offsets that move us out of virtual size */
-if (x + mode-HDisplay  xf86_config-maxWidth ||
-   y + mode-VDisplay  xf86_config-maxHeight)
-{
-   if (x + mode-HDisplay  xf86_config-maxWidth)
-   crtc-x = xf86_config-maxWidth - mode-HDisplay;
-   if (y + mode-VDisplay  xf86_config-maxHeight)
-   crtc-y = xf86_config-maxHeight - mode-VDisplay;
-   if (crtc-x  0 || crtc-y  0)
-   {
-   xf86DrvMsg (scrn-scrnIndex, X_ERROR,
-   Mode %dx%d does not fit virtual size %dx%d - 
-   internal error\n, mode-HDisplay, mode-VDisplay,
-   xf86_config-maxWidth, xf86_config-maxHeight);
-   goto done;
-   }
-   xf86DrvMsg (scrn-scrnIndex, X_ERROR,
-   Mode %dx%d+%d+%d does not fit virtual size %dx%d - 
-   offset updated to +%d+%d\n,
-   mode-HDisplay, mode-VDisplay, x, y,
-   xf86_config-maxWidth, xf86_config-maxHeight,
-   crtc-x, crtc-y);
-}
-
 if (crtc-funcs-set_origin 
memcmp (mode, saved_mode, sizeof(saved_mode)) == 0 
-   saved_rotation == rotation) {
+   saved_rotation == rotation 
+   saved_transform_present == crtc-transformPresent 
+   (!crtc-transformPresent || RRTransformEqual(saved_transform, 
crtc-transform)))
+{
+   if (!xf86CrtcRotate (crtc))
+   goto done;
crtc-funcs-set_origin (crtc, crtc-x, crtc-y);
ret = TRUE;
goto done;
@@ -441,8 +422,11 @@ xf86CrtcSetOrigin (xf86CrtcPtr crtc, int x, int y)
 {
 crtc-x = x;
 crtc-y = y;
-if (crtc-funcs-set_origin)
+if (crtc-funcs-set_origin) {
+   if (!xf86CrtcRotate (crtc))
+   return;
crtc-funcs-set_origin (crtc, x, y);
+}
 else
xf86CrtcSetMode (crtc, crtc-mode, crtc-rotation, x, y);
 }
-- 
1.5.6.5

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] Handle matrix computation overflow in RRTransformCompute

[Keith Packard]

If the computation of the composite fixed-point transform for RandR
overflows at any point, take the resulting floating point transform and
scale that back to fit in a fixed point matrix. This ensures that a matrix
will always be available, although perhaps at reduced precision. Someday we
should add floating point matrices to Render.

Signed-off-by: Keith Packard kei...@keithp.com
---
 randr/rrtransform.c |   39 ---
 1 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/randr/rrtransform.c b/randr/rrtransform.c
index a901df4..cc18a06 100644
--- a/randr/rrtransform.c
+++ b/randr/rrtransform.c
@@ -120,6 +120,22 @@ RRTransformCopy (RRTransformPtr dst, RRTransformPtr src)
 
 #define F(x)   IntToxFixed(x)
 
+static void
+RRTransformRescale(struct pixman_f_transform *f_transform, double limit)
+{
+double max = 0, v, scale;
+int i, j;
+
+for (j = 0; j  3; j++)
+   for (i = 0; i  3; i++)
+   if ((v = abs (f_transform-m[j][i]))  max)
+   max = v;
+scale = limit / max;
+for (j = 0; j  3; j++)
+   for (i = 0; i  3; i++)
+   f_transform-m[j][i] *= scale;
+}
+
 /*
  * Compute the complete transformation matrix including
  * client-specified transform, rotation/reflection values and the crtc 
@@ -141,6 +157,7 @@ RRTransformCompute (int x,
 {
 PictTransform  t_transform, inverse;
 struct pixman_f_transform tf_transform, tf_inverse;
+Bool   overflow = FALSE;
 
 if (!transform) transform = t_transform;
 if (!f_transform) f_transform = tf_transform;
@@ -234,7 +251,8 @@ RRTransformCompute (int x,
 #ifdef RANDR_12_INTERFACE
 if (rr_transform)
 {
-pixman_transform_multiply (transform, transform, 
rr_transform-transform);
+if (!pixman_transform_multiply (transform, transform, 
rr_transform-transform))
+   overflow = TRUE;
pixman_f_transform_multiply (f_transform, f_transform, 
rr_transform-f_transform);
pixman_f_transform_multiply (f_inverse, rr_transform-f_inverse, 
f_inverse);
 }
@@ -242,19 +260,26 @@ RRTransformCompute (int   x,
 /*
  * Compute the class of the resulting transform
  */
-if (pixman_transform_is_identity (transform))
+if (!overflow  pixman_transform_is_identity (transform))
 {
pixman_transform_init_translate (transform, F ( x), F ( y));
 
-   pixman_f_transform_init_translate (f_transform, F( x), F( y));
-   pixman_f_transform_init_translate (f_inverse,   F(-x), F(-y));
+   pixman_f_transform_init_translate (f_transform,  x,  y);
+   pixman_f_transform_init_translate (f_inverse,   -x, -y);
return FALSE;
 }
 else
 {
-   pixman_transform_translate (inverse, transform, x, y);
-   pixman_f_transform_translate (f_inverse, f_transform, x, y);
+   pixman_f_transform_translate (f_inverse, f_transform, -x, -y);
+   if (!pixman_transform_translate (inverse, transform, F(-x), F(-y)))
+   overflow = TRUE;
+   if (overflow)
+   {
+   struct pixman_f_transform f_scaled;
+   f_scaled = *f_transform;
+   RRTransformRescale(f_scaled, 16384.0);
+   pixman_transform_from_pixman_f_transform(transform, f_scaled);
+   }
return TRUE;
 }
 }
-
-- 
1.5.6.5

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?

[Michel Dänzer]

On Tue, 2009-02-03 at 23:26 +, Nix wrote:
 
 [dix] Could not init font path element /usr/lib/X11/fonts/OTF, removing from 
 list!
 
 It's hard to check the scrolling behaviour of antialiased and fixed-point text
 when the only font you have is 'fixed' :)

Well, FWIW this only affects core fonts, not client-side fonts.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: about the exa patches

[Michel Dänzer]

On Wed, 2009-02-04 at 00:29 +0100, Maarten Maathuis wrote:
 
 I hope the changes are coming to an end. I still need to know if there
 are any external users of fbDoCopy that would care for a wrapper. I'm
 assuming that functions that changed their return value from void to
 Bool pose no issue, but you're welcome to explain if it's not.
 
 @MrCooper: the approach of patch 8 and 9 is ok by you?

I definitely like the reuse of fbCopyRegion and fbDoCopy; the only minor
niggle I have there would be to replace EXA_WRAPPER with something more
generic like FB_WRAP_PREFIX, and then

#ifdef FB_WRAP_PREFIX
#define fbCopyRegion FB_WRAP_PREFIX##CopyRegion
#define fbDoCopy FB_WRAP_PREFIX##DoCopy
#endif


I'd like the fb changes to be reviewed by an fb hacker.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg