Re: suggestions for 3-monitor display
On Thu, Mar 26, 2009 at 19:13:38 -0700, Glen Lenker wrote: > > Hi everyone, > > I am trying to get my three monitors to work with 2 graphic cards. > > my setup: > Intel integrated G31 > nvidia 8600 GTS > > I was able to get this to work around a year ago with xinerama, but > now that xrandr has more or less xinerama, I can't get X to start up > with xinerama anymore. I can post my xorg.conf and my Xorg.0.log if The Intel driver doesn't support Xinerama anymore (it crashes the Xserver if Xinerama is enabled), and RandR doesn't support more than one card. To get 3 displays, you need to put in one more graphics card that supports Xinerama. Regards, Tino ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: hi, i have got a strange problem with the intel driver on my Intel 965Q Chipset
Dear Alec, I'm a little puzzled. Why the xorg.conf file have the setting about ATI card. Do you wan to use multiple display cards on your Intel platform? If not, I think your conf file is a little confusing. You can make a new configure file using the command "X -configure". Please have a try, thanks! Best wishes, Gordon -Original Message- From: xorg-boun...@lists.freedesktop.org [mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Alec Liu Sent: 2009年3月27日 17:02 To: xorg@lists.freedesktop.org Subject: hi, i have got a strange problem with the intel driver on my Intel 965Q Chipset I want to use the rotation on my screen, both driver '2.6.3-r1' and '2.5.1-r1' can use the rotation. But only '2.5.1-r1' working well. The driver '2.6.3-r1' after rotation, everything is slow, even move the window. Here is the log of both version and my configure. I have no idea why it is happening, please have a look on it, i am not sure if it is a bug or not. btw: when everything is slow, one core of my CPU usage is full. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: hi, i have got a strange problem with the intel driver on my Intel 965Q Chipset
Thanks for the reply. Actually you are right, i am use multiple display cards one ATI one on board intel. But i just disable it in the configure file, you may see it from this section: Section "ServerLayout" Identifier "Multihead layout" #Screen 0 "Screen0" 0 0 Screen 1 "Screen1" #RightOf "Screen0" # Screen 1 "Screen1" InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" #Option "Xinerama" "on" EndSection I will try to make a clear configure file for you. 2009/3/27 : > Dear Alec, >I'm a little puzzled. Why the xorg.conf file have the setting about ATI > card. Do you wan to use multiple display cards on your Intel platform? If > not, I think your conf file is a little confusing. You can make a new > configure file using the command "X -configure". >Please have a try, thanks! > Best wishes, > Gordon > > -Original Message- > From: xorg-boun...@lists.freedesktop.org > [mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Alec Liu > Sent: 2009年3月27日 17:02 > To: xorg@lists.freedesktop.org > Subject: hi, i have got a strange problem with the intel driver on my Intel > 965Q Chipset > > I want to use the rotation on my screen, both driver '2.6.3-r1' and > '2.5.1-r1' can use the rotation. But only '2.5.1-r1' working well. The > driver '2.6.3-r1' after rotation, everything is slow, even move the > window. Here is the log of both version and my configure. I have no > idea why it is happening, please have a look on it, i am not sure if > it is a bug or not. btw: when everything is slow, one core of my CPU > usage is full. > xorg.conf Description: Binary data ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
General ATI TV-out problem with PAL B/G?
Hi! After trying to get TV-out working with two different notebooks on two different TV sets I'm asking myself if the PAL B/G standard is working at all in the radeon and mach64 drivers. The TV output looks very similar with both devices: Black and white "ant wars" screen which is somehow reacting to cursor-movement and moving of windows, but far away from the output I would expect. I looked a bit around in the source code of radeon_tv.c and didn't find any special treatment for 50 MHz PAL standards (only PAL M and PAL 60). I must admit I'm no C programmer and not familiar with X programming either. Has anybody successfully got TV output working in continental europe? I know that the notebook with the radeon card is capable of TV output with the TV set in question when it's running Windows XP, so no hardware problem. Best regards, Andreas Juch signature.asc Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] glx: fix DRI2 memory leak
On Thu, Mar 26, 2009 at 6:33 PM, Jesse Barnes wrote:
> Ok, I think this is where the leak was:
> __glXUnrefDrawable->DrawableGone->__glXUnrefDrawable. This sequence
> meant the glxPriv would stay around (since it was used), but
> DrawableGone had generally already disposed of the pDrawable before the
> call to Unref, so we never got into DRI2DestroyBuffers, thus the leak.
>
> The loop seems broken to me. It *looks* like DrawableGone should be
> the real free routine, only called when a drawable really is free, so
> I've fixed up the code to conform to that. This means removing the GLX
> priv frees from DRI and DRI2 routines and putting them here and using
> the GLX unref routine everwhere (since it will only free the resource
> when the refcount reaches 0).
>
> Any thoughts? I'd appreciate some more testers too... I'm not quite
> sure about the generic DoDestroyDrawable change, but if the refcount is
> always 1 there anyway it shouldn't make a difference and seems more
> correct.
The __GLXdrawable is a reference counted object, and the glx code
references it in a couple of places: when there's an X resource
pointing to it (a GLXWindow, GLXPixmap or GLXPbuffer) and when it's
the current drawable or readable for a context. The __GLXdrawable is
allocated by the backend in use (dri, dri2 or swrast) and must be
freed by the same backend (don't mix alloc and free across abstraction
barriers). We unref the __GLXdrawable when we either set a different
drawable/readable and when the X resource goes away.
The leak is (as you pointed out before) because we NULL the pDraw
pointer before calling the backend destructor, which then can't unref
the DRI2Drawable, which we then leak. You had the right fix in the
originial post, we just need to not touch glxPriv after
__glXUnrefDrawable if it got destroyed. I suggest this change to
DrawableGone in irc:
refcount = glxPriv->refcount;
__glXUnrefDrawable(glxPriv);
if (refcount > 1) {
glxPriv->pDraw = NULL;
glxPriv->drawId = 0;
}
Did you try that?
cheers,
Kristian
> Thanks,
> --
> Jesse Barnes, Intel Open Source Technology Center
>
>
> diff --git a/glx/glxcmds.c b/glx/glxcmds.c
> index ab2d91b..08b866d 100644
> --- a/glx/glxcmds.c
> +++ b/glx/glxcmds.c
> @@ -1222,7 +1222,7 @@ static int DoDestroyDrawable(__GLXclientState *cl, XID
> glxdrawable, int type)
> }
> }
>
> - FreeResource(glxdrawable, FALSE);
> + __glXUnrefDrawable(pGlxDraw);
>
> return Success;
> }
> diff --git a/glx/glxdri.c b/glx/glxdri.c
> index 223b06e..253d868 100644
> --- a/glx/glxdri.c
> +++ b/glx/glxdri.c
> @@ -237,8 +237,6 @@ __glXDRIdrawableDestroy(__GLXdrawable *drawable)
> serverClient, drawable->pDraw);
> __glXleaveServer(GL_FALSE);
> }
> -
> - xfree(private);
> }
>
> static GLboolean
> diff --git a/glx/glxdri2.c b/glx/glxdri2.c
> index 4e76c71..4fdc7df 100644
> --- a/glx/glxdri2.c
> +++ b/glx/glxdri2.c
> @@ -106,8 +106,6 @@ __glXDRIdrawableDestroy(__GLXdrawable *drawable)
> * aready have taken care of this, so only call if pDraw isn't NULL. */
> if (drawable->pDraw != NULL)
> DRI2DestroyDrawable(drawable->pDraw);
> -
> - xfree(private);
> }
>
> static void
> diff --git a/glx/glxext.c b/glx/glxext.c
> index c882372..0b6c752 100644
> --- a/glx/glxext.c
> +++ b/glx/glxext.c
> @@ -120,6 +120,8 @@ static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
> {
> ScreenPtr pScreen = glxPriv->pDraw->pScreen;
>
> + glxPriv->destroy(glxPriv);
> +
> switch (glxPriv->type) {
> case GLX_DRAWABLE_PIXMAP:
> case GLX_DRAWABLE_PBUFFER:
> @@ -129,7 +131,7 @@ static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
>
> glxPriv->pDraw = NULL;
> glxPriv->drawId = 0;
> - __glXUnrefDrawable(glxPriv);
> + xfree(glxPriv);
>
> return True;
> }
> diff --git a/glx/glxutil.c b/glx/glxutil.c
> index bc71087..61323f5 100644
> --- a/glx/glxutil.c
> +++ b/glx/glxutil.c
> @@ -52,11 +52,9 @@ void
> __glXUnrefDrawable(__GLXdrawable *glxPriv)
> {
> glxPriv->refCount--;
> - if (glxPriv->refCount == 0) {
> + if (glxPriv->refCount == 0)
> /* remove the drawable from the drawable list */
> FreeResourceByType(glxPriv->drawId, __glXDrawableRes, FALSE);
> - glxPriv->destroy(glxPriv);
> - }
> }
>
> GLboolean
>
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] glx: fix DRI2 memory leak
On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg wrote:
> On Thu, Mar 26, 2009 at 6:33 PM, Jesse Barnes
> wrote:
> > Ok, I think this is where the leak was:
> > __glXUnrefDrawable->DrawableGone->__glXUnrefDrawable. This sequence
> > meant the glxPriv would stay around (since it was used), but
> > DrawableGone had generally already disposed of the pDrawable before
> > the call to Unref, so we never got into DRI2DestroyBuffers, thus
> > the leak.
> >
> > The loop seems broken to me. It *looks* like DrawableGone should be
> > the real free routine, only called when a drawable really is free,
> > so I've fixed up the code to conform to that. This means removing
> > the GLX priv frees from DRI and DRI2 routines and putting them here
> > and using the GLX unref routine everwhere (since it will only free
> > the resource when the refcount reaches 0).
> >
> > Any thoughts? I'd appreciate some more testers too... I'm not
> > quite sure about the generic DoDestroyDrawable change, but if the
> > refcount is always 1 there anyway it shouldn't make a difference
> > and seems more correct.
>
> The __GLXdrawable is a reference counted object, and the glx code
> references it in a couple of places: when there's an X resource
> pointing to it (a GLXWindow, GLXPixmap or GLXPbuffer) and when it's
> the current drawable or readable for a context. The __GLXdrawable is
> allocated by the backend in use (dri, dri2 or swrast) and must be
> freed by the same backend (don't mix alloc and free across abstraction
> barriers). We unref the __GLXdrawable when we either set a different
> drawable/readable and when the X resource goes away.
Yeah it does violate the layering... but the uref->drawablegone->unref
is a bit convoluted too.
> The leak is (as you pointed out before) because we NULL the pDraw
> pointer before calling the backend destructor, which then can't unref
> the DRI2Drawable, which we then leak. You had the right fix in the
> originial post, we just need to not touch glxPriv after
> __glXUnrefDrawable if it got destroyed. I suggest this change to
> DrawableGone in irc:
>
> refcount = glxPriv->refcount;
> __glXUnrefDrawable(glxPriv);
> if (refcount > 1) {
> glxPriv->pDraw = NULL;
> glxPriv->drawId = 0;
> }
>
> Did you try that?
Ah no I think I had either >= 1 or == 1 which clearly wouldn't work
since the glxPriv would be gone in the == 1 case. I'll try the >1 test.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Bug in Xextproto
Hi,
I'm bitten by this issue too and I'm somewhat lost with this. The patch
has not yet been applied or commented on xorg, so I just want to make
sure it's seen.
8yrgr4dkp...@dyweni.com wrote:
Just noticed that I created the reverse patch. Here to correct one.
Hey Everyone,
I found a bug in Xextproto that break QT. QT fails to compile because
of namespace pollution from . It's the same problem that
inputproto had, which Adam Jackson fixed with git commit
b5cbe2d93f6c0129b8f29da97778f6d1b15c38f9.
I created and successfully tested the attached patch. It's based on
the the Adam's fix for inputproto. With this patch, I was able to
compile and install QT.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
diff --git a/Xge.h b/Xge.h
index cc03ece..51382ff 100644
--- a/Xge.h
+++ b/Xge.h
@@ -30,7 +30,6 @@
#ifndef _XGE_H_
#define _XGE_H_
-#include
#include
#include
@@ -39,12 +38,15 @@ _XFUNCPROTOBEGIN
/**
* Generic Event mask.
* To be used whenever a list of masks per extension has to be provided.
+ *
+ * But, don't actually use the CARD{8,16,32} types. We can't get them them
+ * defined here without polluting the namespace.
*/
typedef struct {
-CARD8 extension;
-CARD8 pad0;
-CARD16 pad1;
-CARD32 evmask;
+unsigned char extension;
+unsigned char pad0;
+unsigned short pad1;
+unsigned int evmask;
} XGenericEventMask;
Bool XGEQueryExtension(Display* dpy, int *event_basep, int *err_basep);
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Commit 5100d829a4d71ce4a9fbc2b81694a1fb90066ccf causing problems with mythtv
Well for those following along and catching this from google and what not, i've identified a solution to this. If you are using mesa 7.3, you'll need to add this commit from mesa git: +From 529d1d720e1422bad1880ef33fae1c9423112d2e Mon Sep 17 00:00:00 2001 +From: Eric Anholt +Date: Wed, 04 Feb 2009 03:29:11 + +Subject: swrast: Add support for x8r8g8b8 fbconfig. + +This lets swrast produce an fbconfig suitable for the root visual now that +the server's not allowing mismatched fbconfigs. It's not currently targeted at release 7.4, but I proposed it get added. Regards On Tue, Mar 24, 2009 at 09:26, Mario Limonciello wrote: > Hi: > > I've been attempting to debug a bug that recently entered Ubuntu jaunty [1] > related to MythTV. It seems that a whole slew of X BadMatch errors and > RenderBadPicture errors are thrown out whenever a QWidget show call is > used. Using git-bisect, I came to the conclusion it got introduced at this > commit in the xorg-server 1.6 branch: > > commit 8b967b24690cb072fc37c463eceb2b886cef80c4 > Author: Eric Anholt > Date: Mon Feb 2 10:13:46 2009 -0800 > > glx: Don't match fbconfigs to visuals with mismatched channel masks. > > This fixes at least one known bug, where the depth 32 visual would end > up > with a depth 24 fbconfig attached, angering compiz. > (cherry picked from commit 5100d829a4d71ce4a9fbc2b81694a1fb90066ccf) > > Signed-off-by: Keith Packard > > Having no in depth knowledge of this code, I'm at a bit of a loss of > whether to point fingers at QT3 that some patch is necessary, or if this is > a genuine problem with Xorg. > > [1] https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/341898 > > Regards, > > -- > Mario Limonciello > supe...@gmail.com > Sent from: Austin Texas United States. -- Mario Limonciello supe...@gmail.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Bug in Xextproto
Le 27/03/2009 19:55, Simon Thum a écrit : > Hi, > > I'm bitten by this issue too and I'm somewhat lost with this. The patch > has not yet been applied or commented on xorg, so I just want to make > sure it's seen. Then render.h also needs something like this... Can't we work something out with Qt folks? Cheers Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] glx: fix DRI2 memory leak
On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg wrote:
> On Thu, Mar 26, 2009 at 6:33 PM, Jesse Barnes
> wrote:
> > Ok, I think this is where the leak was:
> > __glXUnrefDrawable->DrawableGone->__glXUnrefDrawable. This sequence
> > meant the glxPriv would stay around (since it was used), but
> > DrawableGone had generally already disposed of the pDrawable before
> > the call to Unref, so we never got into DRI2DestroyBuffers, thus
> > the leak.
> >
> > The loop seems broken to me. It *looks* like DrawableGone should be
> > the real free routine, only called when a drawable really is free,
> > so I've fixed up the code to conform to that. This means removing
> > the GLX priv frees from DRI and DRI2 routines and putting them here
> > and using the GLX unref routine everwhere (since it will only free
> > the resource when the refcount reaches 0).
> >
> > Any thoughts? I'd appreciate some more testers too... I'm not
> > quite sure about the generic DoDestroyDrawable change, but if the
> > refcount is always 1 there anyway it shouldn't make a difference
> > and seems more correct.
>
> The __GLXdrawable is a reference counted object, and the glx code
> references it in a couple of places: when there's an X resource
> pointing to it (a GLXWindow, GLXPixmap or GLXPbuffer) and when it's
> the current drawable or readable for a context. The __GLXdrawable is
> allocated by the backend in use (dri, dri2 or swrast) and must be
> freed by the same backend (don't mix alloc and free across abstraction
> barriers). We unref the __GLXdrawable when we either set a different
> drawable/readable and when the X resource goes away.
>
> The leak is (as you pointed out before) because we NULL the pDraw
> pointer before calling the backend destructor, which then can't unref
> the DRI2Drawable, which we then leak. You had the right fix in the
> originial post, we just need to not touch glxPriv after
> __glXUnrefDrawable if it got destroyed. I suggest this change to
> DrawableGone in irc:
>
> refcount = glxPriv->refcount;
> __glXUnrefDrawable(glxPriv);
> if (refcount > 1) {
> glxPriv->pDraw = NULL;
> glxPriv->drawId = 0;
> }
Yep, that seems to work too... Magnus or Vasily can you guys confirm?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/glx/glxext.c b/glx/glxext.c
index c882372..fec45b7 100644
--- a/glx/glxext.c
+++ b/glx/glxext.c
@@ -119,6 +119,7 @@ static int ContextGone(__GLXcontext* cx, XID id)
static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
{
ScreenPtr pScreen = glxPriv->pDraw->pScreen;
+int refcount;
switch (glxPriv->type) {
case GLX_DRAWABLE_PIXMAP:
@@ -127,9 +128,12 @@ static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
break;
}
-glxPriv->pDraw = NULL;
-glxPriv->drawId = 0;
+refcount = glxPriv->refCount;
__glXUnrefDrawable(glxPriv);
+if (refcount > 1) {
+ glxPriv->pDraw = NULL;
+ glxPriv->drawId = 0;
+}
return True;
}
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
