Re: General ATI TV-out problem with PAL B/G?
On 3/27/09, Andreas Juch wrote: > 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. PAL should work fine depending on what chip you are using. If you are using an r1xx-r3xx based IGP chip, tv-out only works on NSTC at the moment. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] glx: fix DRI2 memory leak
Shuang He wrote:
Jesse Barnes wrote:
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,
Memory leak problem seems resolved, but I still see X crash with:
(gdb) bt
#0 0xb7fd5424 in __kernel_vsyscall ()
#1 0x03155660 in raise () from /lib/libc.so.6
#2 0x03157028 in abort () from /lib/libc.so.6
#3 0x031925bd in __libc_message () from /lib/libc.so.6
#4 0x031987e4 in malloc_printerr () from /lib/libc.so.6
#5 0x0319c441 in _int_realloc () from /lib/libc.so.6
#6 0x0319d176 in realloc () from /lib/libc.so.6
#7 0x08131002 in Xrealloc (ptr=0x6, amount=0) at utils.c:1133
#8 0x0806d10b in dixAllocatePrivate (privates=0x91487c8, key=0xb7e90a3c)
at privates.c:129
#9 0x0806d1cc in dixSetPrivate (privates=0x91487c8, key=0xb7e90a3c, val=0x0)
at privates.c:193
#10 0xb7e8eca1 in DRI2DestroyDrawable (pDraw=0x91487b0) at dri2.c:218
#11 0xb7eee668 in __glXDRIdrawableDestroy (drawable=0x9205ff0) at glxdri2.c:108
#12 0xb7ee49bb in __glXUnrefDrawable (glxPriv=0x9205ff0) at glxutil.c:58
#13 0xb7ee3183 in DrawableGone (glxPriv=0x9205ff0, xid=12583326)
at glxext.c:131
#14 0x0806efdc in FreeResource (id=12583326, skipDeleteFuncType=0)
at resource.c:561
#15 0xb7edffa6 in DoDestroyDrawable (cl=,
glxdrawable=12583326, type=1) at glxcmds.c:1225
#16 0xb7ee340a in __glXDispatch (client=0x8d79db8) at glxext.c:523
#17 0x080874cf in Dispatch () at dispatch.c:437
---Type to continue, or q to quit---
#18 0x0806c69d in main (argc=2, argv=0xbf9d2754, envp=Cannot access memory at
address 0xbde
Thanks
--Shuang
) at main.c:397
Just debug a bit, check out this series of calls in DRI2DestroyDrawable when X
crashed:
in (*ds->DestroyBuffers)(pDraw, pPriv->buffers, pPriv->bufferCount);
Xfree: free(0x9eef330)
Xfree: free(0x9eeef20)
Xfree: free(0x9efdde0)
Xfree: free(0x9efce08)
Xfree: free(0x9eee8b0)
Xrealloc: ptr = 0x9efaf20
Xrealloc: amount = 384
Xfree: free(0x9efcd18)
Xfree: free(0x9ef8468)
Xrealloc: ptr = 0x9efa278
Xrealloc: amount = 384
Xfree: free(0x9efcd18)
Xfree: free(0x9ef9808)
Xfree: free(0x9eeef38)
Xfree: free(0x9efa648)
Xfree: free(0x9efd788)
in dixSetPrivate(&pPixmap->devPrivates, dri2PixmapPrivateKey, NULL);
Xrealloc: ptr = 0x9efce08
Xrealloc: amount = 512
So dixSetPrivate is trying to realloc memory at 0x9efce08, which is alreay
freed in DetroyBuffers. So maybe we should also do this:
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 0f2e24b..dddcfdc 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -204,9 +204,6 @@ DRI2DestroyDrawable(DrawablePtr pDraw)
if (pPriv->refCount > 0)
return;
-(*ds->DestroyBuffers)(pDraw, pPriv->buffers, pPriv->bufferCount);
-xfree(pPriv);
-
if (pDraw->type == DRAWABLE_WINDOW)
{
pWin = (WindowPtr) pDraw;
@@ -217,6 +214,9 @@ DRI2DestroyDrawable(DrawablePtr pDraw)
pPixmap = (PixmapPtr) pDra
Re: [RFC] glx: fix DRI2 memory leak
Jesse Barnes wrote:
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,
Memory leak problem seems resolved, but I still see X crash with:
(gdb) bt
#0 0xb7fd5424 in __kernel_vsyscall ()
#1 0x03155660 in raise () from /lib/libc.so.6
#2 0x03157028 in abort () from /lib/libc.so.6
#3 0x031925bd in __libc_message () from /lib/libc.so.6
#4 0x031987e4 in malloc_printerr () from /lib/libc.so.6
#5 0x0319c441 in _int_realloc () from /lib/libc.so.6
#6 0x0319d176 in realloc () from /lib/libc.so.6
#7 0x08131002 in Xrealloc (ptr=0x6, amount=0) at utils.c:1133
#8 0x0806d10b in dixAllocatePrivate (privates=0x91487c8, key=0xb7e90a3c)
at privates.c:129
#9 0x0806d1cc in dixSetPrivate (privates=0x91487c8, key=0xb7e90a3c, val=0x0)
at privates.c:193
#10 0xb7e8eca1 in DRI2DestroyDrawable (pDraw=0x91487b0) at dri2.c:218
#11 0xb7eee668 in __glXDRIdrawableDestroy (drawable=0x9205ff0) at glxdri2.c:108
#12 0xb7ee49bb in __glXUnrefDrawable (glxPriv=0x9205ff0) at glxutil.c:58
#13 0xb7ee3183 in DrawableGone (glxPriv=0x9205ff0, xid=12583326)
at glxext.c:131
#14 0x0806efdc in FreeResource (id=12583326, skipDeleteFuncType=0)
at resource.c:561
#15 0xb7edffa6 in DoDestroyDrawable (cl=,
glxdrawable=12583326, type=1) at glxcmds.c:1225
#16 0xb7ee340a in __glXDispatch (client=0x8d79db8) at glxext.c:523
#17 0x080874cf in Dispatch () at dispatch.c:437
---Type to continue, or q to quit---
#18 0x0806c69d in main (argc=2, argv=0xbf9d2754, envp=Cannot access memory at
address 0xbde
Thanks
--Shuang
) at main.c:397
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ANN: xterm patch #243
On Sun, 29 Mar 2009, Thomas Dickey wrote: > On Sun, 29 Mar 2009, Matthieu Herrb wrote: > >> Thomas Dickey wrote: >>> Patch #243 - 2009/3/28 >>> >> >>> * add "DEF_ALLOW_XXX" definitions to main.h to allow overriding the >>>default compiled-in values for "allowxxx" resources. >> >> Hi, >> >> I noticed a cut'n'pasto in the default for AllowWindowOps in >> charproc.c:401, your using DEF_ALLOW_FONT instread of DEF_ALLOW_WINDOW. > > thanks (will fix...) current diffs here: ftp://invisible-island.net/temp/xterm-243b.patch.gz -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ANN: xterm patch #243
On Sun, 29 Mar 2009, Matthieu Herrb wrote: > Thomas Dickey wrote: >> Patch #243 - 2009/3/28 >> > >> * add "DEF_ALLOW_XXX" definitions to main.h to allow overriding the >>default compiled-in values for "allowxxx" resources. > > Hi, > > I noticed a cut'n'pasto in the default for AllowWindowOps in > charproc.c:401, your using DEF_ALLOW_FONT instread of DEF_ALLOW_WINDOW. thanks (will fix...) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ANN: xterm patch #243
Thomas Dickey wrote: > Patch #243 - 2009/3/28 > > * add "DEF_ALLOW_XXX" definitions to main.h to allow overriding the >default compiled-in values for "allowxxx" resources. Hi, I noticed a cut'n'pasto in the default for AllowWindowOps in charproc.c:401, your using DEF_ALLOW_FONT instread of DEF_ALLOW_WINDOW. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fedora 10, xrandr and inFocus projector
>> Alex, >> Re-reading your statements, perhaps I can solve the issue by activating the >> non-KMS code. If so, how can I do that? > > boot with nomodeset on the kernel command line (edit the kernel > command line in grub when the computer boots up, or edit your grub > config and reboot) IIRC. > > Alex > Alex, You da man! That worked! Thanks much! scott ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fedora 10, xrandr and inFocus projector
On 3/29/09, Scott C. Frase wrote: > > > > > > If you are using F10 with kernel modesetting (KMS) it doesn't have the > > > proper quirks do deal with the broken connector table on the macbooks. > > > I think the non-KMS code shipped with F10 should have the proper > > > quirk handling, if not, you may need to upgrade your ddx. > > > > > > Alex > > > > > > > Alex, > > However, you just went way over my head with that statement. Can you give > me the dummies version of that? IE, what's ddx and how do I upgrade? > > > > thanks much, > > scott > > > > > Alex, > Re-reading your statements, perhaps I can solve the issue by activating the > non-KMS code. If so, how can I do that? boot with nomodeset on the kernel command line (edit the kernel command line in grub when the computer boots up, or edit your grub config and reboot) IIRC. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fedora 10, xrandr and inFocus projector
>> If you are using F10 with kernel modesetting (KMS) it doesn't have the >> proper quirks do deal with the broken connector table on the macbooks. >> I think the non-KMS code shipped with F10 should have the proper >> quirk handling, if not, you may need to upgrade your ddx. >> >> Alex > > Alex, > However, you just went way over my head with that statement. Can you give me > the dummies version of that? IE, what's ddx and how do I upgrade? > > thanks much, > scott > Alex, Re-reading your statements, perhaps I can solve the issue by activating the non-KMS code. If so, how can I do that? scott ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fedora 10, xrandr and inFocus projector
> If you are using F10 with kernel modesetting (KMS) it doesn't have the > proper quirks do deal with the broken connector table on the macbooks. > I think the non-KMS code shipped with F10 should have the proper > quirk handling, if not, you may need to upgrade your ddx. > > Alex Alex, However, you just went way over my head with that statement. Can you give me the dummies version of that? IE, what's ddx and how do I upgrade? thanks much, scott ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fedora 10, xrandr and inFocus projector
On 3/29/09, Scott C. Frase wrote: > Hi guys, > I'm a new user to the list with, what else, a sticky problem. I have a > dual boot MacBook Pro (2.33Ghz Core 2 Duo) that runs both Leopard and > Fedora 10, x86-64 using ReFit as the boot loader. I am trying to connect > an InFocus projector to the DVI output of the Mac while running under Fedora. > > The InFocus is connected this way: > MacBook external DVI output > DVI-VGA dongle > VGA - M1-DA cable > InFocus > M1-DA connector > > Unfortunately, the problem is that though xrandr sees the DVI-0 port as > connected, the InFocus doesn't get the signal or spring to life through > the setup listed above. > > I've verified that the DVI-0 output works with a regular DVI cable > connected to the DVI input on my Dell LCD panel. So this means a > digital signal is being output from the port. Now, I've also verified > that the DVI-0 output from Fedora does NOT work with the DVI-VGA dongle > connected to the VGA input on the Dell. When connected with the DVI-VGA > setup listed above, xrandr sees that the InFocus is connected (shown > below). Also, Gnome sees the InFocus in the connected displays. > > On the flipside, I've verified that the InFocus projector works > using the DVI-VGA cable setup when booted from the Mac OS. So that's > odd. > > Since I can see the output while connected to the Dell's DVI input, I > don't think this is a configuration issue. But maybe Fedora just doesn't > like the DVI-VGA dongle. I'm sure I could buy an M1-DA direct to DVI > adapter and be done with it, but I'd rather save the $55 and figure out > why the Mac sees the Infocus, but why Fedora has troubles. If you are using F10 with kernel modesetting (KMS) it doesn't have the proper quirks do deal with the broken connector table on the macbooks. I think the non-KMS code shipped with F10 should have the proper quirk handling, if not, you may need to upgrade your ddx. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Fedora 10, xrandr and inFocus projector
Hi guys, I'm a new user to the list with, what else, a sticky problem. I have a dual boot MacBook Pro (2.33Ghz Core 2 Duo) that runs both Leopard and Fedora 10, x86-64 using ReFit as the boot loader. I am trying to connect an InFocus projector to the DVI output of the Mac while running under Fedora. The InFocus is connected this way: MacBook external DVI output > DVI-VGA dongle > VGA - M1-DA cable > InFocus M1-DA connector Unfortunately, the problem is that though xrandr sees the DVI-0 port as connected, the InFocus doesn't get the signal or spring to life through the setup listed above. I've verified that the DVI-0 output works with a regular DVI cable connected to the DVI input on my Dell LCD panel. So this means a digital signal is being output from the port. Now, I've also verified that the DVI-0 output from Fedora does NOT work with the DVI-VGA dongle connected to the VGA input on the Dell. When connected with the DVI-VGA setup listed above, xrandr sees that the InFocus is connected (shown below). Also, Gnome sees the InFocus in the connected displays. On the flipside, I've verified that the InFocus projector works using the DVI-VGA cable setup when booted from the Mac OS. So that's odd. Since I can see the output while connected to the Dell's DVI input, I don't think this is a configuration issue. But maybe Fedora just doesn't like the DVI-VGA dongle. I'm sure I could buy an M1-DA direct to DVI adapter and be done with it, but I'd rather save the $55 and figure out why the Mac sees the Infocus, but why Fedora has troubles. Here is the output of xrandr: [...@cm ~]$ xrandr Screen 0: minimum 320 x 200, current 2464 x 900, maximum 2720 x 1924 LVDS connected 1440x900+0+0 (normal left inverted right x axis y axis) 331mm x 207mm 1440x900 60.0*+ 2048x1536 60.0 1920x1440 60.0 1856x1392 60.0 1792x1344 75.0 60.0 1600x1200 85.0 75.0 70.0 65.0 60.0 1400x1050 74.8 60.0 1280x1024 85.0 75.0 60.0 DVI-0 connected 1024x768+1440+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.0*+ 85.0 75.1 75.0 70.1 60.0* 1400x1050 60.0 1280x1024 75.0 60.0 1024x768_60.00 60.0 1280x960 60.0 1152x864 75.0 832x62474.6 800x60085.1 72.2 75.0 60.3 56.2 640x48085.0 72.8 75.0 72.8 75.0 60.0 720x40085.0 640x40085.1 640x35085.1 0x0 0.0 Here is my xorg.conf: Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen0" 0 0 InputDevice"Keyboard0" "CoreKeyboard" InputDevice"Synaptics Touchpad" "CorePointer" EndSection Section "Module" Load "synaptics" Load "extmod" Load "dbe" Load "glx" EndSection Section "InputDevice" Identifier "Synaptics Touchpad" Driver "synaptics" Option "SendCoreEvents" "true" Option "Device" "/dev/input/mice" Option "Protocol" "auto-dev" Option "SHMConfig" "true" Option "LeftEdge" "10" Option "RightEdge" "1200" Option "TopEdge" "10" Option "BottomEdge" "370" Option "FingerLow" "10" Option "FingerHigh" "20" Option "MaxTapTime" "180" Option "MaxTapMove" "220" Option "SingleTapTimeout" "100" Option "MaxDoubleTapTime" "180" Option "LockedDrags" "off" Option "MinSpeed" "1.10" Option "MaxSpeed" "1.30" Option "AccelFactor" "0.08" Option "TapButton1" "1" Option "TapButton2" "3" Option "TapButton3" "2" Option "RTCornerButton" "0" Option "RBCornerButton" "0" Option "LTCornerButton" "0" Option "LBCornerButton" "0" Option "VertScrollDelta" "20" Option "HorizScrollDelta" "50" Option "HorizEdgeScroll" "0" Option "VertEdgeScroll" "0" Option "VertTwoFingerScroll" "1" Option "HorizTwoFingerScroll" "1" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "us" EndSection Section "Device" Identifier "ATI Technologies Inc M56P [Radeon Mobility X1600]" Driver "radeon" Option "backingstore" "true" Option "RenderAccel" "true" Option "AccelMethod" "EXA" Option "Monitor-LVDS" "Internal Monitor" Option "Monitor-DVI-0" "External DVI" BusID "PCI:1:0:0" EndSection Section "Monitor" Identifier "Internal Monitor" HorizSync 30.0 - 110.0 VertRefresh 50.0 - 150.0 Option "DPMS" End
