Bug#443936: xserver-xorg-video-mga: windowmaker and 1.9.99 get along terribly
kls wrote: I finally got around to upgrading my laptop (ATI M6LY)'s install of sid, and found that this is *not* a problem in the mga driver. It's a problem in some other random xorg component, presumably libxcomposite1. To work around it, I have to disable both the Composite extension and AIGLX -- it seems that with only one disabled the other caused it to be re-enabled. (Any suggestions on tracing down what's actually wrong?) (e.g. Section Extensions Option Composite disable EndSection Section ServerFlags Option AIGLX no EndSection ) So I guess that means this bug should either be moved to a different package or closed. If I understand correctly, you are seeing WindowMaker being very slow on both MGA and ATI with Xorg 7.3 (xserver-xorg-core 1.4) when AIGLX/Composite is enabled? And it worked fine before? Does it help if you switch to EXA on ATI? EXA shouldn't as bad as in MGA on your board. Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443936: xserver-xorg-video-mga: windowmaker and 1.9.99 get along terribly
kls wrote: I finally got around to upgrading my laptop (ATI M6LY)'s install of sid, and found that this is *not* a problem in the mga driver. It's a problem in some other random xorg component, presumably libxcomposite1. To work around it, I have to disable both the Composite extension and AIGLX -- it seems that with only one disabled the other caused it to be re-enabled. (Any suggestions on tracing down what's actually wrong?) (e.g. Section Extensions Option Composite disable EndSection Section ServerFlags Option AIGLX no EndSection ) So I guess that means this bug should either be moved to a different package or closed. If I understand correctly, you are seeing WindowMaker being very slow on both MGA and ATI with Xorg 7.3 (xserver-xorg-core 1.4) when AIGLX/Composite is enabled? And it worked fine before? Does it help if you switch to EXA on ATI? EXA shouldn't as bad as in MGA on your board. EXA on ATI is usable ( although I think it's barely perceptably slower than composite-less XAA ) but compositing/aiglx(?) still has the other non-speed related bugs: * wmnet's window contents being placed in the wrong location * windowmaker's shaped transient indicating which workspace I'm on isn't shaped * wmxmms quits with an obscure GDK error. (This happens even when not running under windowmaker) For the heck of it I tried xcompmgr, and on my ATI windowmaker's decorations are all differently wrong than on my MGA -- on the ATI they all seem to be in a brighten only mode, whereas on the MGA they're all pure transparent. Thank you, - Robert Jacobs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443936: xserver-xorg-video-mga: windowmaker and 1.9.99 get along terribly
On Thu, 2007-10-04 at 11:32 -0400, kls wrote: EXA on ATI is usable ( although I think it's barely perceptably slower than composite-less XAA ) but compositing/aiglx(?) still has the other non-speed related bugs: * wmnet's window contents being placed in the wrong location * windowmaker's shaped transient indicating which workspace I'm on isn't shaped * wmxmms quits with an obscure GDK error. (This happens even when not running under windowmaker) For the heck of it I tried xcompmgr, and on my ATI windowmaker's decorations are all differently wrong than on my MGA -- on the ATI they all seem to be in a brighten only mode, whereas on the MGA they're all pure transparent. Can you provide screenshots? It's weird that merely enabling the Composite extension or AIGLX would cause this - they should have no effect unless their features are actively used by clients. (Also, AIGLX is not really enabled when the DRI is disabled, as in the log file of the original report.) Some older clients used to have trouble with Composite's ARGB visuals - does setting the environment variable XLIB_SKIP_ARGB_VISUALS=1 for running windowmaker make a difference? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#443936: xserver-xorg-video-mga: windowmaker and 1.9.99 get along terribly
On Thu, 2007-10-04 at 11:32 -0400, kls wrote: EXA on ATI is usable ( although I think it's barely perceptably slower than composite-less XAA ) but compositing/aiglx(?) still has the other non-speed related bugs: * wmnet's window contents being placed in the wrong location * windowmaker's shaped transient indicating which workspace I'm on isn't shaped * wmxmms quits with an obscure GDK error. (This happens even when not running under windowmaker) For the heck of it I tried xcompmgr, and on my ATI windowmaker's decorations are all differently wrong than on my MGA -- on the ATI they all seem to be in a brighten only mode, whereas on the MGA they're all pure transparent. Can you provide screenshots? It's weird that merely enabling the Composite extension or AIGLX would cause this - they should have no effect unless their features are actively used by clients. (Also, AIGLX is not really enabled when the DRI is disabled, as in the log file of the original report.) Some older I've reconfigured things so many times by now in the process of trying to figure things out... clients used to have trouble with Composite's ARGB visuals - does setting the environment variable XLIB_SKIP_ARGB_VISUALS=1 for running windowmaker make a difference? Putting that in the general environment fixes all the graphical errors I've yet noticed. Do you still want screenshots? - robert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443936: xserver-xorg-video-mga: windowmaker and 1.9.99 get along terribly
On Thu, 2007-10-04 at 12:45 -0400, kls wrote: clients used to have trouble with Composite's ARGB visuals - does setting the environment variable XLIB_SKIP_ARGB_VISUALS=1 for running windowmaker make a difference? Putting that in the general environment fixes all the graphical errors I've yet noticed. Do you still want screenshots? I don't think that's necessary, thanks. Then this looks like a bug in windowmaker or bugs in the apps, depending on whether it also happens with other window managers. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#443936: xserver-xorg-video-mga: windowmaker and 1.9.99 get along terribly
kls wrote: The previously observed abysmal 2d performance seems to be triggered by WindowMaker. This does not seem to be a compositing problem, because it is identical regardless of whether I have DRI enabled or not. It also appears independent of number of active screens. All windows take approximately 1 sec / MPixel to draw on my computer (1GHz athlon) Hi Brice -- I finally got around to upgrading my laptop (ATI M6LY)'s install of sid, and found that this is *not* a problem in the mga driver. It's a problem in some other random xorg component, presumably libxcomposite1. To work around it, I have to disable both the Composite extension and AIGLX -- it seems that with only one disabled the other caused it to be re-enabled. (Any suggestions on tracing down what's actually wrong?) (e.g. Section Extensions Option Composite disable EndSection Section ServerFlags Option AIGLX no EndSection ) So I guess that means this bug should either be moved to a different package or closed. Anyway, thanks for your assistance! - Robert Jacobs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443936: xserver-xorg-video-mga: windowmaker and 1.9.99 get along terribly
The problem could related to the acceleration architecture. You're using the default right now (XAA). Does it help if you add: [...] Or maybe the new architecture EXA would be better (I don't know how good it is in the mga driver so far). Does it help if you add Option AccelMethod EXA instead of the above NoAccel line? [...] At the moment, MGA's EXA implementation is only usable if you use Option MigrationHeuristic greedy So I've tried using windowmaker with EXA (using greedy) and it's faster than plain XAA (about 200%), although I want to think that it's slower than in the past, and it is definitely slower than w/ openbox. If I start xcompmgr, it is effectively the same (slow exposes c) speed as before, but windowmaker has effectively all its decorations 100% transparent (with lettering inside opaque). Using transset to set non-100% opacity approximately does the right thing, but returning it to 100% opacity reverts to the original incorrect rendering. - robert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443936: xserver-xorg-video-mga: windowmaker and 1.9.99 get along terribly
k l s [2007-09-25 14:35]: I have pretty much no idea what to look at here. So I am CCing Tilman (the upstream dev). I didn't use WindowMaker recently so I don't have any idea what it looks like these days. Do you have the same problem in you start an empty session with something like startx /usr/bin/xterm ? I've tried using openbox w/ an xterm and it has no problems. Interesting! I'm clueless as to what's going on though. I'll try to look into it in the next days. The problem could related to the acceleration architecture. You're using the default right now (XAA). Does it help if you add: Option NoAccel true to the Device section of your xorg.conf? It will disable XAA acceleration completely. NoAccel is slower than I recall accelerated having been in the past (as it ought). I think it starts faster than the standard XAA acceleration, but it gets slower as windows are repeatedly exposed. Some kind of resource starvation? Or maybe the new architecture EXA would be better (I don't know how good it is in the mga driver so far). Does it help if you add Option AccelMethod EXA instead of the above NoAccel line? I think I remember having read that EXA isn't ready yet, but I tried it for the heck of it. It's tremendously slower. At the moment, MGA's EXA implementation is only usable if you use Option MigrationHeuristic greedy Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpgzPFhj5z0i.pgp Description: PGP signature
Bug#443936: xserver-xorg-video-mga: windowmaker and 1.9.99 get along terribly
kls wrote: The previously observed abysmal 2d performance seems to be triggered by WindowMaker. This does not seem to be a compositing problem, because it is identical regardless of whether I have DRI enabled or not. It also appears independent of number of active screens. All windows take approximately 1 sec / MPixel to draw on my computer (1GHz athlon) at least two dockapps dislike the environment: wmnet's window contents are drawn in the wrong place (upper right corner rather than in a window) wmxmms crashes with Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 139 error_code 8 request_code 62 minor_code 0 I'd suggest this is a problem in 1.9.99 (as opposed to windowmaker) because it worked correctly with all older drivers. I have pretty much no idea what to look at here. So I am CCing Tilman (the upstream dev). I didn't use WindowMaker recently so I don't have any idea what it looks like these days. Do you have the same problem in you start an empty session with something like startx /usr/bin/xterm ? The problem could related to the acceleration architecture. You're using the default right now (XAA). Does it help if you add: Option NoAccel true to the Device section of your xorg.conf? It will disable XAA acceleration completely. Or maybe the new architecture EXA would be better (I don't know how good it is in the mga driver so far). Does it help if you add Option AccelMethod EXA instead of the above NoAccel line? Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443936: xserver-xorg-video-mga: windowmaker and 1.9.99 get along terribly
I have pretty much no idea what to look at here. So I am CCing Tilman (the upstream dev). I didn't use WindowMaker recently so I don't have any idea what it looks like these days. Do you have the same problem in you start an empty session with something like startx /usr/bin/xterm ? I've tried using openbox w/ an xterm and it has no problems. The problem could related to the acceleration architecture. You're using the default right now (XAA). Does it help if you add: Option NoAccel true to the Device section of your xorg.conf? It will disable XAA acceleration completely. NoAccel is slower than I recall accelerated having been in the past (as it ought). I think it starts faster than the standard XAA acceleration, but it gets slower as windows are repeatedly exposed. Some kind of resource starvation? Or maybe the new architecture EXA would be better (I don't know how good it is in the mga driver so far). Does it help if you add Option AccelMethod EXA instead of the above NoAccel line? I think I remember having read that EXA isn't ready yet, but I tried it for the heck of it. It's tremendously slower. Thank you! - robert jacobs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443936: xserver-xorg-video-mga: windowmaker and 1.9.99 get along terribly
Package: xserver-xorg-video-mga Version: 1:1.9.99.dfsg.1-1 Severity: normal The previously observed abysmal 2d performance seems to be triggered by WindowMaker. This does not seem to be a compositing problem, because it is identical regardless of whether I have DRI enabled or not. It also appears independent of number of active screens. All windows take approximately 1 sec / MPixel to draw on my computer (1GHz athlon) at least two dockapps dislike the environment: wmnet's window contents are drawn in the wrong place (upper right corner rather than in a window) wmxmms crashes with Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 139 error_code 8 request_code 62 minor_code 0 I'd suggest this is a problem in 1.9.99 (as opposed to windowmaker) because it worked correctly with all older drivers. thank you! - robert jacobs -- Package-specific info: Contents of /var/lib/x11/X.roster: xserver-xorg /etc/X11/X target does not match checksum in /var/lib/x11/X.md5sum. X server symlink status: lrwxrwxrwx 1 root root 13 2006-12-14 13:23 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1669528 2007-09-16 14:56 /usr/bin/Xorg Contents of /var/lib/x11/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400/G450 (rev 82) /etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum. Xorg X server configuration file status: lrwxrwxrwx 1 root root 16 2007-09-22 15:15 /etc/X11/xorg.conf - xorg.conf-2h-pos Contents of /etc/X11/xorg.conf: Section ServerLayout Identifier X.org Configured Screen mga InputDeviceMouse0 CorePointer InputDeviceKeyboard0 CoreKeyboard EndSection Section Files RgbPath /etc/X11/rgb ModulePath /usr/lib/xorg/modules FontPath /usr/local/share/fonts/Type1 FontPath /usr/local/share/fonts/TrueType FontPath /usr/share/fonts/X11/misc FontPath /usr/share/fonts/X11/cyrillic FontPath /usr/share/fonts/X11/Type1 FontPath /usr/share/fonts/X11/100dpi/:unscaled FontPath /usr/share/fonts/X11/75dpi/:unscaled FontPath /usr/share/fonts/X11/100dpi FontPath /usr/share/fonts/X11/75dpi FontPath /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module Load dbe Load extmod Load record Load xtrap Load type1 Load xrandr EndSection Section ServerFlags Option DontZap true Option AllowDeactivateGrabs true Option AllowClosedownGrabs true # ew, xinerama EndSection Section InputDevice Identifier Keyboard0 Driver kbd EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/input/mice Option ZAxisMapping 4 5 6 7 EndSection Section Monitor # crtc2 doesn't support doublescanning. sigh. ModeLine 1152x900 100 1152 1176 1272 1456 900 924 938 952 +hsync +vsync ModeLine 1152x864 100 1152 1176 1272 1456 864 864 878 916 +hsync +vsync ModeLine 576x432 50 576 586 644 728 432 432 439 458 +hsync +vsync doublescan # this mode is such a stretch. we actually lose a few scanlines to the top, # but for stupid software... ModeLine 640x480 53.868 640 640 736 784 480 480 487 493 +hsync +vsync doublescan ModeLine 640x400 55 640 668 732 800 400 400 407 425 +hsync +vsync doublescan # stupid modes ModeLine 320x240 50 320 454 512 728 240 280 287 458 +hsync +vsync doublescan ModeLine 192x144 50 192 402 460 728 144 180 187 458 +hsync +vsync doublescan # can't draw anything lower than (640-or-466)x350 (771 minimum scanlines) # don't have 640x350 # have 640x400, 640x480 # can't have 800x600 (1200 is way too large, 600 will be too large) # have 1024x768, 1152x864 # could probably have 1280x960, but eh # i.e. valid # of pixel lines: 350-480 700-960 Option PreferredMode 1152x900 DisplaySize 390 293 Identifier r20gs VendorName radius ModelNameTwo Page Display / 20gs HorizSync67 - 70 VertRefresh 69-89 EndSection Section Monitor ModeLine 1152x900 100 1152 1176 1272 1456 900 924 938 952 +hsync +vsync ModeLine 1152x864 100 1152 1176 1272 1456 864 864 878 916 +hsync +vsync ModeLine 576x432 50 576 586 644 728 432 432 439 458 +hsync +vsync doublescan ModeLine 640x480 53.868 640 640 736 784 480 480 487 493 +hsync +vsync doublescan ModeLine 640x400 55 640 668 732 800 400 400 407 425 +hsync +vsync doublescan Option PreferredMode 1152x900 # Option RightOf r20gs DisplaySize 390 293 Identifier r20gs2 VendorName radius ModelNameTwo Page Display / 20gs HorizSync67 - 70
