Re: [compiz] unredirect_fullscreen_windows

[Douglas Bollinger]

On Mon, 23 Apr 2007 18:02:08 +0200
dragoran <[EMAIL PROTECTED]> wrote:

> Please see https://bugs.freedesktop.org/show_bug.cgi?id=9474
> (last comment) its a nvidia driver issue, also look at the benchmarks I 
> made, you don't really need it on nvidia cards.

Benchmarks can be misleading with this bug.

For instance, with the game oolite (a elite clone with OpenGL graphics), the
FPS is almost identical with or without unredirect_fullscreen_windows enabled.
However, when you actually play the game, it's very noticeable that the game
is in fact really lagging.  It's like the game "sticks" every few seconds.

Yes, I'm using a Nvidia card.

-- 
Economists state their GNP growth projections to the nearest tenth of a
percentage point to prove they have a sense of humor.
-- Edgar R. Fiedler
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

[compiz] [PATCH] Fix unredirect fullscreen windows

[James Jones]

While trying to reproduce an error with input handling and 
unredirect fullscreen windows, I noticed the option didn't work at 
all in compiz master.  This patch gets it working again.

Thanks,
-James Jones

nvpublic
From b117578b09cc97ab516affc189015924a5776855 Mon Sep 17 00:00:00 2001
From: James Jones <[EMAIL PROTECTED]>
Date: Mon, 23 Apr 2007 17:59:03 -0700
Subject: [PATCH] Fix unredirect fullscreen windows.

In paint.c!paintScreenRegion():

-Need to subtract window's region from tmpRegion
 before checking if tmpRegion is NULL.

-Don't try to draw the unredirected window, as
 it will be immediately redirected again by
 paint.c!drawWindow()
---
 src/paint.c |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/paint.c b/src/paint.c
index a486672..9ce076c 100644
--- a/src/paint.c
+++ b/src/paint.c
@@ -160,6 +160,7 @@ paintScreenRegion (CompScreen	   *sc
 CompWindow*w;
 CompCursor	  *c;
 int		  count, windowMask, backgroundMask;
+CompWindow	  *fullscreenWindow = NULL;
 
 if (!tmpRegion)
 {
@@ -201,6 +202,8 @@ paintScreenRegion (CompScreen	   *sc
 	if ((*screen->paintWindow) (w, &w->paint, transform, tmpRegion,
 PAINT_WINDOW_OCCLUSION_DETECTION_MASK))
 	{
+	XSubtractRegion (tmpRegion, w->region, tmpRegion);
+
 	/* unredirect top most fullscreen windows. */
 	if (count == 0	  &&
 		!REGION_NOT_EMPTY (tmpRegion)			  &&
@@ -208,9 +211,8 @@ paintScreenRegion (CompScreen	   *sc
 		XEqualRegion (w->region, &screen->region))
 	{
 		unredirectWindow (w);
+		fullscreenWindow = w;
 	}
-
-	XSubtractRegion (tmpRegion, w->region, tmpRegion);
 	}
 
 	count++;
@@ -224,6 +226,9 @@ paintScreenRegion (CompScreen	   *sc
 	if (w->destroyed)
 	continue;
 
+	if (w == fullscreenWindow)
+	continue;
+
 	if (!w->shaded)
 	{
 	if (w->attrib.map_state != IsViewable || !w->damaged)
-- 
1.4.2.4

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

[compiz] [PATCH] Fix some bind/releaseTexImage errors

[James Jones]

Found this while debugging some driver issues.  It fixes errors when 
non-TFP textures were bound/unbound when strict binding is used.

Thanks,
-James Jones

nvpublic
From d559571515245e3696a63b8a1c615a5cca4bc51a Mon Sep 17 00:00:00 2001
From: James Jones <[EMAIL PROTECTED]>
Date: Mon, 23 Apr 2007 17:28:12 -0700
Subject: [PATCH] Only use bindTexImage and releaseTexImage on textures
that have associated pixmaps.
---
 src/texture.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/texture.c b/src/texture.c
index 3d87d06..384ae3d 100644
--- a/src/texture.c
+++ b/src/texture.c
@@ -390,7 +390,7 @@ enableTexture (CompScreen	 *screen,
 glEnable (texture->target);
 glBindTexture (texture->target, texture->name);
 
-if (strictBinding)
+if (strictBinding && texture->pixmap)
 {
 	(*screen->bindTexImage) (screen->display->display,
  texture->pixmap,
@@ -469,7 +469,7 @@ disableTexture (CompScreen  *screen,
 		CompTexture *texture)
 {
 makeScreenCurrent (screen);
-if (strictBinding)
+if (strictBinding && texture->pixmap)
 {
 	glBindTexture (texture->target, texture->name);
 
-- 
1.4.2.4

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

[compiz] Re: ATI and GLX_EXT_texture_from_pixmap error

[Colin Guthrie]

Paul Wellner Bou wrote:
> Perhaps I'll by an nvidia soon.

Or an intel... support the company that appears to be giving more back
to the Open Source community :)

Col

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

[compiz] GL_ARB_fragment_program is missed

[Denis F. Latypoff]

Hello compiz,

  I have mobility radeon 7500, radeon driver, xorg 7.2, ubuntu 7.04,
  latest git compiz. 

  Seems that GL_ARB_fragment_program is missed in my video
  card/driver. Is it mean that I will never get blur working?

  blurdemo shows only transparent white window.
  I run gtk-window-decorator --blur all.

-- 
Best regards,
 Denis  mailto:[EMAIL PROTECTED]

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

Re: [compiz] ATI and GLX_EXT_texture_from_pixmap error

[Paul Wellner Bou]

Hello,

you might want to see the end of this topic on the GLX_EXT_tfp extension 
as well (basically see if the extension appears in all 3 sections of the 
glxinfo output):

http://forum.compiz.org/viewtopic.php?t=92&highlight=


Thank you for this hint. This was the problem. I upgraded to Xorg 7.2 
(in debian experimental) and it works there. Thanks again.
Although I won't use it... as it is slower as I thought it was. I saw it 
on my old Laptop (i815, celeron 1.13, 256 RAM) and it worked almost 
great there, but with my 1600x1200 screen here... puh...

Perhaps I'll by an nvidia soon.

Regards
Paul.

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

Re: [compiz] [PATCH] Remove timeout callback

[David Reveman]

On Mon, 2007-04-23 at 17:10 +0100, Mike Dransfield wrote:
> Mike Dransfield wrote:
> > David Reveman wrote:
> >> On Mon, 2007-04-23 at 16:14 +0100, Mike Dransfield wrote:
> >>  
> >>> David Reveman wrote:
> >>>
>  On Mon, 2007-04-23 at 14:28 +0100, Mike Dransfield wrote:
> 
> > While working on the python plugin, I realised that the
> > timeout system does not allow for notification when a timeout
> > is removed.  This has been fine up until now because he closures
> > never needed to be cleaned up.
> >
> > In the python plugin, I pass through a custom structure which
> > needs to be cleaned up if the timeout is removed.  This is almost
> > certainly the cause of some horrible memory leaks for me.
> >
> > The attached patch is a simple solution to the problem.  I think
> > it should be good enough for most situations.
> >
> > I could maintain some sort of lookup inside my plugin, but I think
> > other plugins would benefit from this.
> >
> > It is OK to go in or were there any comments?
> > 
>  Timeouts are only removed as a result of the timeout call-back 
>  function
>  returning FALSE. So unless I'm missing something, all cleanup can be
>  done in the regular call-back function before returning FALSE.
> 
>  
> >>> The pyplane (and the original plane) use a timeout which gets
> >>> canceled if the user quickly switches back to another viewport.
> >>> It is not a problem for plane because the closure is a CompScreen
> >>> which does not need to be cleaned up.
> >>>
> >>> The plugins call compRemoveTimeout to stop it.  I'm not sure if this
> >>> is right in this case, but it seems that it would be useful to stop a
> >>> timeout before it expires, and it makes it easy to clean up the closure
> >>> without having to maintain a lookup table of handles to closures.
> >>> 
> >>
> >> OK, I see.
> >> 1. compRemoveTimeout can return the closure pointer.
> >>
> >> 2. We add a function like this:
> >>
> >> void *
> >> compTimeoutGetUserData (CompTimeoutHandle handle);
> >>
> >> 3. We add a remove call-back function (your patch).
> >>
> >>
> >> I'm in favor of solution 1, it's simple and efficient. What do you
> >> think?
> >>   
> >
> > Yes, number 1 sounds like a better solution.
> >
> > Ill prepare some patches for that.  Should I also increase the
> > ABIVERSION when I do this?
> 
> Attached is the diff for that.

good, please commit.

- David

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

Re: [compiz] [PATCH] Remove timeout callback

[David Reveman]

On Mon, 2007-04-23 at 17:00 +0100, Mike Dransfield wrote:
> David Reveman wrote:
> > On Mon, 2007-04-23 at 16:14 +0100, Mike Dransfield wrote:
> >   
> >> David Reveman wrote:
> >> 
> >>> On Mon, 2007-04-23 at 14:28 +0100, Mike Dransfield wrote:
> >>>   
> >>>   
>  While working on the python plugin, I realised that the
>  timeout system does not allow for notification when a timeout
>  is removed.  This has been fine up until now because he closures
>  never needed to be cleaned up.
> 
>  In the python plugin, I pass through a custom structure which
>  needs to be cleaned up if the timeout is removed.  This is almost
>  certainly the cause of some horrible memory leaks for me.
> 
>  The attached patch is a simple solution to the problem.  I think
>  it should be good enough for most situations.
> 
>  I could maintain some sort of lookup inside my plugin, but I think
>  other plugins would benefit from this.
> 
>  It is OK to go in or were there any comments?
>  
>  
> >>> Timeouts are only removed as a result of the timeout call-back function
> >>> returning FALSE. So unless I'm missing something, all cleanup can be
> >>> done in the regular call-back function before returning FALSE.
> >>>
> >>>   
> >>>   
> >> The pyplane (and the original plane) use a timeout which gets
> >> canceled if the user quickly switches back to another viewport.
> >> It is not a problem for plane because the closure is a CompScreen
> >> which does not need to be cleaned up.
> >>
> >> The plugins call compRemoveTimeout to stop it.  I'm not sure if this
> >> is right in this case, but it seems that it would be useful to stop a
> >> timeout before it expires, and it makes it easy to clean up the closure
> >> without having to maintain a lookup table of handles to closures.
> >> 
> >
> > OK, I see. 
> >
> > 1. compRemoveTimeout can return the closure pointer.
> >
> > 2. We add a function like this:
> >
> > void *
> > compTimeoutGetUserData (CompTimeoutHandle handle);
> >
> > 3. We add a remove call-back function (your patch).
> >
> >
> > I'm in favor of solution 1, it's simple and efficient. What do you
> > think?
> >   
> 
> Yes, number 1 sounds like a better solution.
> 
> Ill prepare some patches for that.  Should I also increase the
> ABIVERSION when I do this?

Great. I don't think that change can cause any ABI breakage but you can
bump the version if you want.

- David

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

Re: [compiz] [PATCH] Remove timeout callback

[Mike Dransfield]

Mike Dransfield wrote:

David Reveman wrote:

On Mon, 2007-04-23 at 16:14 +0100, Mike Dransfield wrote:
 

David Reveman wrote:
   

On Mon, 2007-04-23 at 14:28 +0100, Mike Dransfield wrote:
   

While working on the python plugin, I realised that the
timeout system does not allow for notification when a timeout
is removed.  This has been fine up until now because he closures
never needed to be cleaned up.

In the python plugin, I pass through a custom structure which
needs to be cleaned up if the timeout is removed.  This is almost
certainly the cause of some horrible memory leaks for me.

The attached patch is a simple solution to the problem.  I think
it should be good enough for most situations.

I could maintain some sort of lookup inside my plugin, but I think
other plugins would benefit from this.

It is OK to go in or were there any comments?

Timeouts are only removed as a result of the timeout call-back 
function

returning FALSE. So unless I'm missing something, all cleanup can be
done in the regular call-back function before returning FALSE.



The pyplane (and the original plane) use a timeout which gets
canceled if the user quickly switches back to another viewport.
It is not a problem for plane because the closure is a CompScreen
which does not need to be cleaned up.

The plugins call compRemoveTimeout to stop it.  I'm not sure if this
is right in this case, but it seems that it would be useful to stop a
timeout before it expires, and it makes it easy to clean up the closure
without having to maintain a lookup table of handles to closures.



OK, I see.
1. compRemoveTimeout can return the closure pointer.

2. We add a function like this:

void *
compTimeoutGetUserData (CompTimeoutHandle handle);

3. We add a remove call-back function (your patch).


I'm in favor of solution 1, it's simple and efficient. What do you
think?
  


Yes, number 1 sounds like a better solution.

Ill prepare some patches for that.  Should I also increase the
ABIVERSION when I do this?


Attached is the diff for that.




- David

  


___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
diff --git a/include/compiz.h b/include/compiz.h
index eb3f142..7906ce2 100644
--- a/include/compiz.h
+++ b/include/compiz.h
@@ -944,7 +944,7 @@ compAddTimeout (int	 time,
 		CallBackProc callBack,
 		void	 *closure);
 
-void
+void *
 compRemoveTimeout (CompTimeoutHandle handle);
 
 CompWatchFdHandle
diff --git a/src/display.c b/src/display.c
index ee092bf..1e22d05 100644
--- a/src/display.c
+++ b/src/display.c
@@ -1082,10 +1082,11 @@ compAddTimeout (int	 time,
 return timeout->handle;
 }
 
-void
+void *
 compRemoveTimeout (CompTimeoutHandle handle)
 {
 CompTimeout *p = 0, *t;
+void*closure = NULL;
 
 for (t = timeouts; t; t = t->next)
 {
@@ -1102,8 +1103,12 @@ compRemoveTimeout (CompTimeoutHandle handle)
 	else
 	timeouts = t->next;
 
+	closure = t->closure;
+
 	free (t);
 }
+
+return closure;
 }
 
 CompWatchFdHandle
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] [PATCH] Remove timeout callback

[Mike Dransfield]

David Reveman wrote:

On Mon, 2007-04-23 at 16:14 +0100, Mike Dransfield wrote:
  

David Reveman wrote:


On Mon, 2007-04-23 at 14:28 +0100, Mike Dransfield wrote:
  
  

While working on the python plugin, I realised that the
timeout system does not allow for notification when a timeout
is removed.  This has been fine up until now because he closures
never needed to be cleaned up.

In the python plugin, I pass through a custom structure which
needs to be cleaned up if the timeout is removed.  This is almost
certainly the cause of some horrible memory leaks for me.

The attached patch is a simple solution to the problem.  I think
it should be good enough for most situations.

I could maintain some sort of lookup inside my plugin, but I think
other plugins would benefit from this.

It is OK to go in or were there any comments?



Timeouts are only removed as a result of the timeout call-back function
returning FALSE. So unless I'm missing something, all cleanup can be
done in the regular call-back function before returning FALSE.

  
  

The pyplane (and the original plane) use a timeout which gets
canceled if the user quickly switches back to another viewport.
It is not a problem for plane because the closure is a CompScreen
which does not need to be cleaned up.

The plugins call compRemoveTimeout to stop it.  I'm not sure if this
is right in this case, but it seems that it would be useful to stop a
timeout before it expires, and it makes it easy to clean up the closure
without having to maintain a lookup table of handles to closures.



OK, I see. 


1. compRemoveTimeout can return the closure pointer.

2. We add a function like this:

void *
compTimeoutGetUserData (CompTimeoutHandle handle);

3. We add a remove call-back function (your patch).


I'm in favor of solution 1, it's simple and efficient. What do you
think?
  


Yes, number 1 sounds like a better solution.

Ill prepare some patches for that.  Should I also increase the
ABIVERSION when I do this?


- David

  


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

Re: [compiz] unredirect_fullscreen_windows

[dragoran]

Is that option working?

With compiz 0.3.0 it worked but fullscreen apps (like Quake 3, Unreal
Tournament 2004, ..) didn't get any mouse input then.

With compiz 0.5.0 it doesn't seem to have any effect (eg. fullscreen
apps are lagging, because of the redirection).

AIGLX, NVidia drivers 1.0-9755.
Key: /apps/compiz/general/screen0/options/unredirect_fullscreen_windows

  

Hello,
Please see https://bugs.freedesktop.org/show_bug.cgi?id=9474
(last comment) its a nvidia driver issue, also look at the benchmarks I 
made, you don't really need it on nvidia cards.


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

Re: [compiz] [PATCH] Remove timeout callback

[David Reveman]

On Mon, 2007-04-23 at 16:14 +0100, Mike Dransfield wrote:
> David Reveman wrote:
> > On Mon, 2007-04-23 at 14:28 +0100, Mike Dransfield wrote:
> >   
> >> While working on the python plugin, I realised that the
> >> timeout system does not allow for notification when a timeout
> >> is removed.  This has been fine up until now because he closures
> >> never needed to be cleaned up.
> >>
> >> In the python plugin, I pass through a custom structure which
> >> needs to be cleaned up if the timeout is removed.  This is almost
> >> certainly the cause of some horrible memory leaks for me.
> >>
> >> The attached patch is a simple solution to the problem.  I think
> >> it should be good enough for most situations.
> >>
> >> I could maintain some sort of lookup inside my plugin, but I think
> >> other plugins would benefit from this.
> >>
> >> It is OK to go in or were there any comments?
> >> 
> >
> > Timeouts are only removed as a result of the timeout call-back function
> > returning FALSE. So unless I'm missing something, all cleanup can be
> > done in the regular call-back function before returning FALSE.
> >
> >   
> 
> The pyplane (and the original plane) use a timeout which gets
> canceled if the user quickly switches back to another viewport.
> It is not a problem for plane because the closure is a CompScreen
> which does not need to be cleaned up.
> 
> The plugins call compRemoveTimeout to stop it.  I'm not sure if this
> is right in this case, but it seems that it would be useful to stop a
> timeout before it expires, and it makes it easy to clean up the closure
> without having to maintain a lookup table of handles to closures.

OK, I see. 

1. compRemoveTimeout can return the closure pointer.

2. We add a function like this:

void *
compTimeoutGetUserData (CompTimeoutHandle handle);

3. We add a remove call-back function (your patch).


I'm in favor of solution 1, it's simple and efficient. What do you
think?

- David

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

Re: [compiz] [PATCH] Resize improvements (Multiple resize modes, better aspect ratio constraining)

[Danny Baumann]

Hi,

> 0001-Added-options-for-additional-resize-modes.patch - I think I'll just
> leave this patch out and add these options once we converted the resize
> plugin to use the new metadata system.

Yes, that's ok as it has the same effect ;-)

> 0002-Added-painting-code-for-additional-resize-modes.patch - I think we
> want the paintWindow function to paint it's own instance of the window
> like switcher and scale plugins are doing instead of transforming the
> core instance. The outline drawing is OK.

No big deal, will change that (although I still think that for things
like resizing/minimization we should go with modifying the core instance
because I don't see why we should add a second fake window instance -
but we discussed this earlier ;-) ).

> 0003-Update-resize-logic-to-reflect-additional-resize-mod.patch - I see
> a lot of calls to damageScreen in this patch when damageScreenRegion
> should be used in all those cases to avoid redrawing more than we need.
> Motion events shouldn't cause the window to be move when resizing in
> stretch-mode and rightEdge, bottomEdge variables can be removed once
> that's changed.

So you mean the window should just be translated in stretch mode? That
makes a lot of sense, right. You're also right about the damageScreen
calls (I don't think the difference will be huge as these calls are
executed very rarely, but I get your point).

> 0004-Added-proper-constraining-code.patch - I hope we can avoid
> including all this code and instead improve the core constraint function
> to solve any problems that currently exist. Can you provide some details
> on how the constraining is not currently working properly in the resize
> plugin so we can discuss how to best solve that?

The main point the current constraining code is lacking are the
following:

1) ability to apply only a subset of all the constraints (e.g. only
applying minimum/maximum size constraints) - no big deal with passing a
bit mask to constrainNewWindowSize

2) abilitity to resize windows with aspect ratio hint set to other
directions than the lower right 
The code in the patch (which was taken from Metacity) takes the resize
direction into account in order to compute the best possible window size
depending on the resize direction. The problem that I see here is: how
to pass the direction of resizing to constrainNewWindowSize properly?
Perhaps we could pass it using an enum and assume some default behaviour
when there is no clear direction (e.g. when called from
addWindowSizeChanges).

> 0005-Warp-pointer-if-resizing-hit-constraints-to-avoid-mo.patch - I had
> something similar to this in the resize plugin before but removed it as
> it can't be done properly, it will always look bad as the cursor can
> never be constrained perfectly. I'd like to avoid this completely.

Ok.

> 0006-Added-screen-damages-which-were-missing-if-the-resiz.patch - Again,
> damageScreen should never have to be called. You want to use
> damageScreenRegion.

Right, will update this.

> 0007-Avoid-resizing-windows-to-negative-sizes.patch - The constrain size
> code should be fixed to take care of this if it doesn't already.

It does, but there is some weird effect when only one coordinate is
negative. In my testing, the size (-1|700) became something like (20|
20). I will have a look into this if there is a more appropriate
solution than that patch.

> 0008-Avoid-window-flashing-back-to-its-old-size-for-a-sho.patch - Does
> this have to be a special case? Can't we have the final size change
> always be the indication that the resizing is done (not only for stretch
> mode)?

I'm not sure if I completely got your question, but the problem is as
follows: 
-  resize done 
-> configureXWindow is called 
-> server information is updated 
-> ... (server processing) 
-> (drawing during that time using the not updated w->attrib
coordinates) 
-> server processing finished, resizeWindow is called, w->attrib is
updated

If you have any suggestion on how to avoid that flashing back during the
server round trip, please let me know.

Regards,

Danny

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

[compiz] change how vertices are generated

[David Reveman]

We need to change the way vertices are generated for windows. We
currently have a addWindowGeometry screen function that takes care of
this. It can be wrapped by plugins and it can generate any vertices and
texture coordinates it wants.

I'd like to change it so that the region for which to generate vertices
and texture coordinates will be specified elsewhere and it doesn't have
to be constrained to the dimensions of the texture.

The reason for this is that when adding support for input
transformations we need to be able to transform not only the coordinates
within the visible part of the window but any coordinate that can be
reported in events that are generated with respect to the window.

Another thing that we need to changed is the way animations are
initiated and performed. Plugins are currently sort of hijacking the
addWindowGeometry function when they feel appropriate without the code
that initiated the animation knowing anything about it. A better model
would be to have the code that can cause an animation to happen also be
the code that initiates the animation. E.g. instead of having the wobbly
plugin deform the window geometry while the move plugin is moving a
window, the move plugin should initiate an animation object and be
responsible for making the animation advance.

- David

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

Re: [compiz] [PATCH] Remove timeout callback

[Mike Dransfield]

David Reveman wrote:

On Mon, 2007-04-23 at 14:28 +0100, Mike Dransfield wrote:
  

While working on the python plugin, I realised that the
timeout system does not allow for notification when a timeout
is removed.  This has been fine up until now because he closures
never needed to be cleaned up.

In the python plugin, I pass through a custom structure which
needs to be cleaned up if the timeout is removed.  This is almost
certainly the cause of some horrible memory leaks for me.

The attached patch is a simple solution to the problem.  I think
it should be good enough for most situations.

I could maintain some sort of lookup inside my plugin, but I think
other plugins would benefit from this.

It is OK to go in or were there any comments?



Timeouts are only removed as a result of the timeout call-back function
returning FALSE. So unless I'm missing something, all cleanup can be
done in the regular call-back function before returning FALSE.

  


The pyplane (and the original plane) use a timeout which gets
canceled if the user quickly switches back to another viewport.
It is not a problem for plane because the closure is a CompScreen
which does not need to be cleaned up.

The plugins call compRemoveTimeout to stop it.  I'm not sure if this
is right in this case, but it seems that it would be useful to stop a
timeout before it expires, and it makes it easy to clean up the closure
without having to maintain a lookup table of handles to closures.


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

Re: [compiz] [PATCH] Remove timeout callback

[David Reveman]

On Mon, 2007-04-23 at 14:28 +0100, Mike Dransfield wrote:
> While working on the python plugin, I realised that the
> timeout system does not allow for notification when a timeout
> is removed.  This has been fine up until now because he closures
> never needed to be cleaned up.
> 
> In the python plugin, I pass through a custom structure which
> needs to be cleaned up if the timeout is removed.  This is almost
> certainly the cause of some horrible memory leaks for me.
> 
> The attached patch is a simple solution to the problem.  I think
> it should be good enough for most situations.
> 
> I could maintain some sort of lookup inside my plugin, but I think
> other plugins would benefit from this.
> 
> It is OK to go in or were there any comments?

Timeouts are only removed as a result of the timeout call-back function
returning FALSE. So unless I'm missing something, all cleanup can be
done in the regular call-back function before returning FALSE.

- David

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

Re: [compiz] --skip-gl-yield

[David Reveman]

On Sat, 2007-04-21 at 19:32 -0300, okasion wrote:
> >>On Thu, 2007-04-19 at 11:25 +0100, Joel Calado wrote:
> >> Beryl has a --skip-gl-yield ( I think now managed by
> --force-nvidia,
> >> dont really know though), that eases the use of beryl under heavy
> CPU 
> >> load.
> >>
> >> Is this implemented in compiz? Cause compiz is _REALLY_ slow under
> >> heavy cpu use for me.
> 
> >That's a driver specific trick that doesn't belong in compiz.
> Setting 
> >__GL_YIELD manually as some people have already suggested >should do
> the
> >same thing and you're of course free to patch compiz so it does >this
> >automatically if you find that useful but a patch like that is
> likely 
> >never going to be accepted upstream.
> >
> >- David
> 
> I'd like to add that before Compiz 0.3.6, the __GL_YIELD fix worked
> without problems for most people, but after this version, the fix
> didnt work anymore using --indirect-rendering, which is a need for
> some people like me, that gets better performance results without
> using direct rendering. 
> This has already been discussed many times, but we are still affected
> by this problem.

What problem? If I remember correctly --strict-binding was made default
in 0.3.6 and you have to pass --loose-binding to get more efficient
behavior that was default before. Could this be related?

I don't think the __GL_YIELD trick will ever make a difference if you
use indirect rendering.

- David

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

Re: [compiz] [PATCH] Resize improvements (Multiple resize modes, better aspect ratio constraining)

[David Reveman]

On Wed, 2007-04-18 at 10:45 +0200, Danny Baumann wrote:
> Hi,
> 
> > I have ported various improvements of Beryl's resize to Compiz:
> > 
> > - multiple resize modes (aside to the standard "normal" mode those are
> > "Stretch", "Outline" and "Filled Outline")
> > - better aspect ratio constraining (you now also can resize aspect
> > constrained windows from other edges than the lower right)
> > - avoiding of mouse pointer desynchronization when the resizing hit
> > constraints.
> > 
> > While porting this, I cleaned up the code and fixed some performance
> > problems, so the code is supposed to work without problems.
> > 
> > If you want to use the new options and are using gconf, you have to do
> > 'make compiz.schemas.in' in your plugin directory to update the schema
> > file.
> > 
> > Please tell me what you think of that patch and if you experience any
> > problems while using it.
> 
> I've splitted up the patch into several smaller ones, adapted them for
> latest API changes and fixed some minor bugs which I got reported.
> 
> Some more feedback would still be nice :-)
> 
> David, are there any objections against including this code?
> 
> Regards,

0001-Added-options-for-additional-resize-modes.patch - I think I'll just
leave this patch out and add these options once we converted the resize
plugin to use the new metadata system.

0002-Added-painting-code-for-additional-resize-modes.patch - I think we
want the paintWindow function to paint it's own instance of the window
like switcher and scale plugins are doing instead of transforming the
core instance. The outline drawing is OK.

0003-Update-resize-logic-to-reflect-additional-resize-mod.patch - I see
a lot of calls to damageScreen in this patch when damageScreenRegion
should be used in all those cases to avoid redrawing more than we need.
Motion events shouldn't cause the window to be move when resizing in
stretch-mode and rightEdge, bottomEdge variables can be removed once
that's changed.

0004-Added-proper-constraining-code.patch - I hope we can avoid
including all this code and instead improve the core constraint function
to solve any problems that currently exist. Can you provide some details
on how the constraining is not currently working properly in the resize
plugin so we can discuss how to best solve that?

0005-Warp-pointer-if-resizing-hit-constraints-to-avoid-mo.patch - I had
something similar to this in the resize plugin before but removed it as
it can't be done properly, it will always look bad as the cursor can
never be constrained perfectly. I'd like to avoid this completely.

0006-Added-screen-damages-which-were-missing-if-the-resiz.patch - Again,
damageScreen should never have to be called. You want to use
damageScreenRegion.

0007-Avoid-resizing-windows-to-negative-sizes.patch - The constrain size
code should be fixed to take care of this if it doesn't already.

0008-Avoid-window-flashing-back-to-its-old-size-for-a-sho.patch - Does
this have to be a special case? Can't we have the final size change
always be the indication that the resizing is done (not only for stretch
mode)?

- David

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

[compiz] unredirect_fullscreen_windows

[David Gerber]

Is that option working?

With compiz 0.3.0 it worked but fullscreen apps (like Quake 3, Unreal
Tournament 2004, ..) didn't get any mouse input then.

With compiz 0.5.0 it doesn't seem to have any effect (eg. fullscreen
apps are lagging, because of the redirection).

AIGLX, NVidia drivers 1.0-9755.
Key: /apps/compiz/general/screen0/options/unredirect_fullscreen_windows

-- 
Dave - http://zapek.com/

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

[compiz] [PATCH] Remove timeout callback

[Mike Dransfield]

While working on the python plugin, I realised that the
timeout system does not allow for notification when a timeout
is removed.  This has been fine up until now because he closures
never needed to be cleaned up.

In the python plugin, I pass through a custom structure which
needs to be cleaned up if the timeout is removed.  This is almost
certainly the cause of some horrible memory leaks for me.

The attached patch is a simple solution to the problem.  I think
it should be good enough for most situations.

I could maintain some sort of lookup inside my plugin, but I think
other plugins would benefit from this.

It is OK to go in or were there any comments?


>From 4cbf2a803d3203a71f2711851383e21688266a9b Mon Sep 17 00:00:00 2001
From: Mike Dransfield <[EMAIL PROTECTED]>
Date: Mon, 23 Apr 2007 14:26:17 +0100
Subject: [PATCH] Add remove callback to timeouts

---
 include/compiz.h |1 +
 plugins/gconf.c  |2 +-
 plugins/plane.c  |2 +-
 plugins/regex.c  |2 +-
 plugins/rotate.c |4 ++--
 plugins/scale.c  |1 +
 plugins/water.c  |6 +++---
 src/display.c|   18 --
 src/event.c  |2 +-
 src/screen.c |1 +
 src/window.c |2 +-
 11 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/include/compiz.h b/include/compiz.h
index eb3f142..4417319 100644
--- a/include/compiz.h
+++ b/include/compiz.h
@@ -942,6 +942,7 @@ compGetDisplayOptions (CompDisplay *display,
 CompTimeoutHandle
 compAddTimeout (int	 time,
 		CallBackProc callBack,
+		CallBackProc removeCallBack,
 		void	 *closure);
 
 void
diff --git a/plugins/gconf.c b/plugins/gconf.c
index 5d42f35..b3f730f 100644
--- a/plugins/gconf.c
+++ b/plugins/gconf.c
@@ -1070,7 +1070,7 @@ gconfInitDisplay (CompPlugin  *p,
 gconf_client_notify_add (gd->client, APP_NAME, gconfKeyChanged, d,
 			 NULL, NULL);
 
-gd->timeoutHandle = compAddTimeout (KEY_CHANGE_TIMEOUT, gconfTimeout, 0);
+gd->timeoutHandle = compAddTimeout (KEY_CHANGE_TIMEOUT, gconfTimeout, NULL, 0);
 
 return TRUE;
 }
diff --git a/plugins/plane.c b/plugins/plane.c
index e715234..6bd0b5e 100644
--- a/plugins/plane.c
+++ b/plugins/plane.c
@@ -188,7 +188,7 @@ moveViewport (CompScreen *screen,
 	ps->dest_y = -screen->y;
 
 ps->timer = SCROLL_TIME;
-ps->timeoutHandle = compAddTimeout (SCROLL_TIME, endMove, screen);
+ps->timeoutHandle = compAddTimeout (SCROLL_TIME, endMove, NULL, screen);
 
 damageScreen (screen);
 }
diff --git a/plugins/regex.c b/plugins/regex.c
index 1387663..9865fad 100644
--- a/plugins/regex.c
+++ b/plugins/regex.c
@@ -342,7 +342,7 @@ regexInitDisplay (CompPlugin  *p,
 
 /* one shot timeout to which will register the expression handler
after all screens and windows have been initialized */
-compAddTimeout (0, regexRegisterExpHanlder, (void *) d);
+compAddTimeout (0, regexRegisterExpHanlder, NULL, (void *) d);
 
 return TRUE;
 }
diff --git a/plugins/rotate.c b/plugins/rotate.c
index bf6bb95..b52c1fc 100644
--- a/plugins/rotate.c
+++ b/plugins/rotate.c
@@ -1165,7 +1165,7 @@ rotateEdgeFlip (CompScreen  *s,
 	{
 	if (!rs->rotateHandle)
 		rs->rotateHandle =
-		compAddTimeout (rd->flipTime, rotateFlipLeft, s);
+		compAddTimeout (rd->flipTime, rotateFlipLeft, NULL, s);
 
 	rs->moving  = TRUE;
 	rs->moveTo -= 360.0f / s->hsize;
@@ -1205,7 +1205,7 @@ rotateEdgeFlip (CompScreen  *s,
 	{
 	if (!rs->rotateHandle)
 		rs->rotateHandle =
-		compAddTimeout (rd->flipTime, rotateFlipRight, s);
+		compAddTimeout (rd->flipTime, rotateFlipRight, NULL, s);
 
 	rs->moving  = TRUE;
 	rs->moveTo += 360.0f / s->hsize;
diff --git a/plugins/scale.c b/plugins/scale.c
index 42c777b..cc10d89 100644
--- a/plugins/scale.c
+++ b/plugins/scale.c
@@ -1774,6 +1774,7 @@ scaleHandleEvent (CompDisplay *d,
 			ss->hoverHandle =
 compAddTimeout (time,
 		scaleHoverTimeout,
+		NULL,
 		s);
 
 			scaleSelectWindowAt (s, x, y, focus);
diff --git a/plugins/water.c b/plugins/water.c
index d55b939..45cb004 100644
--- a/plugins/water.c
+++ b/plugins/water.c
@@ -1347,7 +1347,7 @@ waterToggleRain (CompDisplay *d,
 	int delay;
 
 	delay = wd->opt[WATER_DISPLAY_OPTION_RAIN_DELAY].value.i;
-	ws->rainHandle = compAddTimeout (delay, waterRainTimeout, s);
+	ws->rainHandle = compAddTimeout (delay, waterRainTimeout, NULL, s);
 	}
 	else
 	{
@@ -1378,7 +1378,7 @@ waterToggleWiper (CompDisplay *d,
 	int delay;
 
 	delay = 2000;
-	ws->wiperHandle = compAddTimeout (delay, waterWiperTimeout, s);
+	ws->wiperHandle = compAddTimeout (delay, waterWiperTimeout, NULL, s);
 	}
 	else
 	{
@@ -1586,7 +1586,7 @@ waterSetDisplayOption (CompPlugin  *plugin,
 		continue;
 
 		compRemoveTimeout (ws->rainHandle);
-		ws->rainHandle = compAddTimeout (value->i, waterRainTimeout, s);
+		ws->rainHandle = compAddTimeout (value->i, waterRainTimeout, NULL, s);
 	}
 	return TRUE;
 	}
diff --git a/src/display.c b/src/displ

Re[2]: [compiz] ATI and GLX_EXT_texture_from_pixmap error

[Denis F. Latypoff]

Hello Paul,

Monday, April 23, 2007, 6:27:37 PM, you wrote:

> Hi Ionnis,

>> Since you have an rv200 (radeon 
>> 7500), you should be using the radeon_dri.so. I don't have any 
>> experience with that driver but should be in good shape.

> Yes, I am using this one.

>> see if AIGLX is enabled:

> AIGLX is working and enabled.

>> check what libraries compiz is using
>> ldd /usr/bin/compiz

> Should be ok. See below.

>> particularly see for the libGL.so.1. Is it the one you are expecting?
>> 
>> when you used LIBGL_ALWAYS_INDIRECT=TRUE, you said the error message 
>> disappears but compiz didn't work. Did it produce any other error message ?

> No, nothing. Starting gtk-window-decorator gives me a lot of warnings:

> [...]
> (gtk-window-decorator:8786): Wnck-WARNING **: Unhandled action type (nil)

> (gtk-window-decorator:8786): Wnck-WARNING **: Unhandled action type (nil)
> [...]

I have the same warnings, also I've noticed a bug with latest git
sources of compiz - no shadows on the top and bottom panels and menus,
kust white squares instead, but all other windows properly have
shadows and compiz working ok generally...

>> are you using SELinux? if yes open the selinux-troubleshooter and see if 
>> there are any warnings for the radeon_dri.so or libGL.so.1

> No, No SELinux. There are no more warnings neither. The only lines I did
> not menture yet are in the Xorg.conf, similar as the error message:

> (WW) AIGLX: 3D driver claims to not support visual 0x23
> (WW) AIGLX: 3D driver claims to not support visual 0x24
> (WW) AIGLX: 3D driver claims to not support visual 0x25
> (WW) AIGLX: 3D driver claims to not support visual 0x26
> (WW) AIGLX: 3D driver claims to not support visual 0x27
> (WW) AIGLX: 3D driver claims to not support visual 0x28
> (WW) AIGLX: 3D driver claims to not support visual 0x29
> (WW) AIGLX: 3D driver claims to not support visual 0x2a
> (WW) AIGLX: 3D driver claims to not support visual 0x2b
> (WW) AIGLX: 3D driver claims to not support visual 0x2c
> (WW) AIGLX: 3D driver claims to not support visual 0x2d
> (WW) AIGLX: 3D driver claims to not support visual 0x2e
> (WW) AIGLX: 3D driver claims to not support visual 0x2f
> (WW) AIGLX: 3D driver claims to not support visual 0x30
> (WW) AIGLX: 3D driver claims to not support visual 0x31
> (WW) AIGLX: 3D driver claims to not support visual 0x32
> (II) AIGLX: Loaded and initialized /usr/lib/dri/radeon_dri.so


>> you might want to see the end of this topic on the GLX_EXT_tfp extension 
>> as well (basically see if the extension appears in all 3 sections of the 
>> glxinfo output):
>> http://forum.compiz.org/viewtopic.php?t=92&highlight=

> I'll check this. Thanks.
> Regards
> Paul.

> P.S.: $ ldd /usr/bin/compiz
>  linux-gate.so.1 =>  (0xe000)
>  libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7f3d000)
>  libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb7f3a000)
>  libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb7f37000)
>  libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7f32000)
>  libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb7f2c000)
>  libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb7f29000)
>  libSM.so.6 => /usr/lib/libSM.so.6 (0xb7f1f000)
>  libICE.so.6 => /usr/lib/libICE.so.6 (0xb7f07000)
>  libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7ded000)
>  libstartup-notification-1.so.0 => 
> /usr/lib/libstartup-notification-1.so.0 (0xb7de5000)
>  libGL.so.1 => /usr/lib/libGL.so.1 (0xb7d86000)
>  libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7d6)
>  libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7c1e000)
>  libX11.so.6 => /usr/lib/libX11.so.6 (0xb7b32000)
>  libXext.so.6 => /usr/lib/libXext.so.6 (0xb7b24000)
>  libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7b2)
>  libz.so.1 => /usr/lib/libz.so.1 (0xb7b0c000)
>  libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7b03000)
>  libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb7afe000)
>  libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7ae7000)
>  libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb7ade000)
>  /lib/ld-linux.so.2 (0xb7f79000)
>  libXau.so.6 => /usr/lib/libXau.so.6 (0xb7adb000)
>  libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7ad5000)

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


-- 
Best regards,
 Denis Latypoff  mailto:[EMAIL PROTECTED]

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

Re: [compiz] ATI and GLX_EXT_texture_from_pixmap error

[Paul Wellner Bou]

Hi Ionnis,

Since you have an rv200 (radeon 
7500), you should be using the radeon_dri.so. I don't have any 
experience with that driver but should be in good shape.


Yes, I am using this one.


see if AIGLX is enabled:


AIGLX is working and enabled.


check what libraries compiz is using
ldd /usr/bin/compiz


Should be ok. See below.


particularly see for the libGL.so.1. Is it the one you are expecting?

when you used LIBGL_ALWAYS_INDIRECT=TRUE, you said the error message 
disappears but compiz didn't work. Did it produce any other error message ?


No, nothing. Starting gtk-window-decorator gives me a lot of warnings:

[...]
(gtk-window-decorator:8786): Wnck-WARNING **: Unhandled action type (nil)

(gtk-window-decorator:8786): Wnck-WARNING **: Unhandled action type (nil)
[...]

are you using SELinux? if yes open the selinux-troubleshooter and see if 
there are any warnings for the radeon_dri.so or libGL.so.1


No, No SELinux. There are no more warnings neither. The only lines I did 
not menture yet are in the Xorg.conf, similar as the error message:


(WW) AIGLX: 3D driver claims to not support visual 0x23
(WW) AIGLX: 3D driver claims to not support visual 0x24
(WW) AIGLX: 3D driver claims to not support visual 0x25
(WW) AIGLX: 3D driver claims to not support visual 0x26
(WW) AIGLX: 3D driver claims to not support visual 0x27
(WW) AIGLX: 3D driver claims to not support visual 0x28
(WW) AIGLX: 3D driver claims to not support visual 0x29
(WW) AIGLX: 3D driver claims to not support visual 0x2a
(WW) AIGLX: 3D driver claims to not support visual 0x2b
(WW) AIGLX: 3D driver claims to not support visual 0x2c
(WW) AIGLX: 3D driver claims to not support visual 0x2d
(WW) AIGLX: 3D driver claims to not support visual 0x2e
(WW) AIGLX: 3D driver claims to not support visual 0x2f
(WW) AIGLX: 3D driver claims to not support visual 0x30
(WW) AIGLX: 3D driver claims to not support visual 0x31
(WW) AIGLX: 3D driver claims to not support visual 0x32
(II) AIGLX: Loaded and initialized /usr/lib/dri/radeon_dri.so


you might want to see the end of this topic on the GLX_EXT_tfp extension 
as well (basically see if the extension appears in all 3 sections of the 
glxinfo output):

http://forum.compiz.org/viewtopic.php?t=92&highlight=


I'll check this. Thanks.
Regards
Paul.

P.S.: $ ldd /usr/bin/compiz
linux-gate.so.1 =>  (0xe000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7f3d000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb7f3a000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb7f37000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7f32000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb7f2c000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb7f29000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xb7f1f000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xb7f07000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7ded000)
libstartup-notification-1.so.0 => 
/usr/lib/libstartup-notification-1.so.0 (0xb7de5000)

libGL.so.1 => /usr/lib/libGL.so.1 (0xb7d86000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7d6)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7c1e000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7b32000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb7b24000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7b2)
libz.so.1 => /usr/lib/libz.so.1 (0xb7b0c000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7b03000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb7afe000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7ae7000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb7ade000)
/lib/ld-linux.so.2 (0xb7f79000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7adb000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7ad5000)

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

Re[2]: [compiz] ATI and GLX_EXT_texture_from_pixmap error

[Denis F. Latypoff]

Hello Paul,

Monday, April 23, 2007, 5:42:51 PM, you wrote:

> Hi Denis,

> Thank you for your answer.
>> try:
>> LIBGL_ALWAYS_INDIRECT=1 compiz --replace --indirect-rendering gconf

> The result is the same as described above. I have no window decorations
> and no working window manager at all.

make sure you have gtk-window-decorator running

>> I also have radeon 7500, wokred well except blur (doesn't working)

> Well, then it must work. It must be possible to localize the problem.

> Regards
> Paul.


> __ NOD32 2211 (20070423) Information __

> This message was checked by NOD32 antivirus system.
>   part000.txt - is OK

> http://www.eset.com




-- 
Best regards,
 Denis Latypoff  mailto:[EMAIL PROTECTED]

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

Re: [compiz] ATI and GLX_EXT_texture_from_pixmap error

[Ioannis Nousias]

I've recently compiled xorg, mesa and drm for my rv250 and I've faced 
few problems that I managed to solve. Since you have an rv200 (radeon 
7500), you should be using the radeon_dri.so. I don't have any 
experience with that driver but should be in good shape.


see if AIGLX is enabled:
grep AIGLX /var/log/Xorg.0.log

check what libraries compiz is using
ldd /usr/bin/compiz

particularly see for the libGL.so.1. Is it the one you are expecting?

when you used LIBGL_ALWAYS_INDIRECT=TRUE, you said the error message 
disappears but compiz didn't work. Did it produce any other error message ?


are you using SELinux? if yes open the selinux-troubleshooter and see if 
there are any warnings for the radeon_dri.so or libGL.so.1



you might want to see the end of this topic on the GLX_EXT_tfp extension 
as well (basically see if the extension appears in all 3 sections of the 
glxinfo output):

http://forum.compiz.org/viewtopic.php?t=92&highlight=


hope this helps
-Ioannis




Paul Wellner Bou wrote:

Hello,

I am trying to install and run compiz on my computer since a few 
months yet and there is no way. Today I checked out the latest git 
version and it does not work neither.
I have a ATI Radeon 7500 rev200 and I think thats the problem. I am 
using the open source radeon driver and xorg with AIGLX (on debian 
testing/unstable). DRI is enabled and working, glxgears, too. The 
output of glxinfo is good, too.


Starting compiz I get this errors:

$ compiz --replace gconf &
libGL warning: 3D driver claims to not support visual 0x4b
compiz: GLX_EXT_texture_from_pixmap is not supported by direct 
rendering context, trying indirect rendering context instead

compiz: GLX_EXT_texture_from_pixmap is missing
compiz: Failed to manage screen: 0
compiz: No manageable screens found on display :0.0

I get a Desktop environment without window manager and without any 
window decorations. I can switch the focus, because I have "focus 
follows mouse" but I can't bring windows to the foreground and I can 
not move the windows.


I spent hours searching for this error messages and I tried all I 
read. Running "LIBGL_ALWAYS_INDIRECT=TRUE compiz --replace gconf" 
does eliminate the error message, but compiz is not working, same 
result.


Does anybody know whats the problem with this error message? Where 
can I start to search for more information? Are there any libraries 
wrong? Is this an issue of the xorg radeon driver?


Thank you very much.
Regards,
Paul.

P.S.: my lspci output:
02:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 
QW [Radeon 7500] (prog-if 00 [VGA])

Subsystem: ATI Technologies Inc Radeon 7500
Flags: bus master, stepping, 66MHz, medium devsel, latency 
32, IRQ 16

Memory at d800 (32-bit, prefetchable) [size=128M]
I/O ports at a000 [size=256]
Memory at e100 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at e000 [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz






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

Re: [compiz] ATI and GLX_EXT_texture_from_pixmap error

[Paul Wellner Bou]

Hi Denis,

Thank you for your answer.

try:
LIBGL_ALWAYS_INDIRECT=1 compiz --replace --indirect-rendering gconf


The result is the same as described above. I have no window decorations 
and no working window manager at all.



I also have radeon 7500, wokred well except blur (doesn't working)


Well, then it must work. It must be possible to localize the problem.

Regards
Paul.

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

[compiz] ATI and GLX_EXT_texture_from_pixmap error

[Paul Wellner Bou]

Hello,

I am trying to install and run compiz on my computer since a few months 
yet and there is no way. Today I checked out the latest git version and 
it does not work neither.
I have a ATI Radeon 7500 rev200 and I think thats the problem. I am 
using the open source radeon driver and xorg with AIGLX (on debian 
testing/unstable). DRI is enabled and working, glxgears, too. The output 
of glxinfo is good, too.


Starting compiz I get this errors:

$ compiz --replace gconf &
libGL warning: 3D driver claims to not support visual 0x4b
compiz: GLX_EXT_texture_from_pixmap is not supported by direct rendering 
context, trying indirect rendering context instead

compiz: GLX_EXT_texture_from_pixmap is missing
compiz: Failed to manage screen: 0
compiz: No manageable screens found on display :0.0

I get a Desktop environment without window manager and without any 
window decorations. I can switch the focus, because I have "focus 
follows mouse" but I can't bring windows to the foreground and I can not 
move the windows.


I spent hours searching for this error messages and I tried all I read. 
Running "LIBGL_ALWAYS_INDIRECT=TRUE compiz --replace gconf" does 
eliminate the error message, but compiz is not working, same result.


Does anybody know whats the problem with this error message? Where can I 
start to search for more information? Are there any libraries wrong? Is 
this an issue of the xorg radeon driver?


Thank you very much.
Regards,
Paul.

P.S.: my lspci output:
02:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW 
[Radeon 7500] (prog-if 00 [VGA])

Subsystem: ATI Technologies Inc Radeon 7500
Flags: bus master, stepping, 66MHz, medium devsel, latency 32, 
IRQ 16

Memory at d800 (32-bit, prefetchable) [size=128M]
I/O ports at a000 [size=256]
Memory at e100 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at e000 [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz