Bug#547892: compiz: Hmm, duplicate of #531591
Package: compiz Version: 0.8.2-6 Severity: normal hmm, it seems this is a duplicate of #531591, which also provides a workaround. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686-bigmem (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages compiz depends on: ii compiz-core 0.8.2-6OpenGL window and compositing mana ii compiz-gnome 0.8.2-6OpenGL window and compositing mana ii compiz-gtk0.8.2-6OpenGL window and compositing mana ii compiz-plugins0.8.2-6OpenGL window and compositing mana compiz recommends no packages. Versions of packages compiz suggests: ii compizconfig-settings-manager 0.8.2-2Compizconfig Settings Manager -- no debconf information This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531591: compiz: Workaround doesn't help
Package: compiz Version: 0.8.2-6 Severity: normal Hi, I am also running into this problem and changing that gconf key didn't help for me. I can still easily segfault compiz by simply clicking (the left) window border, e.g. of a gnome-terminal placed on the background. For me, this renders compiz completely unusable. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686-bigmem (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages compiz depends on: ii compiz-core 0.8.2-6OpenGL window and compositing mana ii compiz-gnome 0.8.2-6OpenGL window and compositing mana ii compiz-gtk0.8.2-6OpenGL window and compositing mana ii compiz-plugins0.8.2-6OpenGL window and compositing mana compiz recommends no packages. Versions of packages compiz suggests: ii compizconfig-settings-manager 0.8.2-2Compizconfig Settings Manager -- no debconf information This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529397: Very very very slow on nVidia Quadro NVS 285
Package: compiz Version: 0.8.2-6 Severity: normal See bug #547892: when starting with compiz (as window manager), it is not slow. But when you restart it with compiz --replace , it is very slow. Quite odd, I'd say. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686-bigmem (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages compiz depends on: ii compiz-core 0.8.2-6OpenGL window and compositing mana ii compiz-gnome 0.8.2-6OpenGL window and compositing mana ii compiz-gtk0.8.2-6OpenGL window and compositing mana ii compiz-plugins0.8.2-6OpenGL window and compositing mana compiz recommends no packages. Versions of packages compiz suggests: ii compizconfig-settings-manager 0.8.2-2Compizconfig Settings Manager -- no debconf information This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547892: compiz: Reproducible
Package: compiz Version: 0.8.2-6 Severity: normal I tried to reproduce it by clicking on the left side of any kind of window and in many cases I got the same error. [ 160.659474] compiz.real[3706]: segfault at b573eeb0 ip b573eeb0 sp bfe40fcc error 15 In other words, it's quite easy to reproduce. Please let me know if I can provide more info. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686-bigmem (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages compiz depends on: ii compiz-core 0.8.2-6OpenGL window and compositing mana ii compiz-gnome 0.8.2-6OpenGL window and compositing mana ii compiz-gtk0.8.2-6OpenGL window and compositing mana ii compiz-plugins0.8.2-6OpenGL window and compositing mana compiz recommends no packages. Versions of packages compiz suggests: ii compizconfig-settings-manager 0.8.2-2Compizconfig Settings Manager -- no debconf information This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547892: segfaults suddenly
Package: compiz Version: 0.8.2-6 Severity: normal It happened again, more precisely, when I was clicking on the left side of a GVIM window to enlarge it in that way. [25983.951944] compiz.real[3724]: segfault at b7f79eb0 ip b7f79eb0 sp bf82261c error 14 in libgmodule-2.0.so.0.2000.5 (deleted)[b7f7d000+3000] Looks like a different error this time, though. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686-bigmem (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages compiz depends on: ii compiz-core 0.8.2-6OpenGL window and compositing mana ii compiz-gnome 0.8.2-6OpenGL window and compositing mana ii compiz-gtk0.8.2-6OpenGL window and compositing mana ii compiz-plugins0.8.2-6OpenGL window and compositing mana compiz recommends no packages. Versions of packages compiz suggests: ii compizconfig-settings-manager 0.8.2-2Compizconfig Settings Manager -- no debconf information This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547892: compiz: segfaults suddenly
Package: compiz Version: 0.8.2-6 Severity: normal I was just doing something like moving a window and all of a sudden compiz crashed (all decorations gone). dmesg says: [109206.570559] compiz.real[13508]: segfault at b5788eb0 ip b5788eb0 sp bfb2312c error 15 Starting compiz again with compiz --replace wasn't very succesful. It started, but everything was very very very slow. Unusable. So, I killed it again and started metacity to type this bug report. This was printed on the terminal when starting compiz again after it crashed: $ compiz --replace [3] 466 ws042498-li...@15:13:~$ Checking for Xgl: not present. xset q doesn't reveal the location of the log file. Using fallback /var/log/Xorg.0.log Detected PCI ID for VGA: 01:00.0 0300: 10de:0165 (rev a1) (prog-if 00 [VGA controller]) Checking for texture_from_pixmap: present. Checking for non power of two support: present. Checking for Composite extension: present. Checking screen 1Comparing resolution (3200x1200) to maximum 3D texture size (4096): Passed. Checking for Software Rasterizer: Not present. Checking for nVidia: present. Checking for FBConfig: present. Checking for Xgl: not present. Backend : ini Integration : true Profile : default Adding plugins Initializing core options...done Initializing decoration options...done Initializing resize options...done Initializing zoom options...done Initializing gnomecompat options...done Initializing workarounds options...done Initializing place options...done Initializing water options...done Initializing wobbly options...done Initializing resizeinfo options...done Initializing animation options...done Initializing animationaddon options...done Initializing fade options...done Initializing move options...done /usr/bin/compiz.real (cube) - Warn: Failed to load slide: /usr/share/gdm/themes/Human/ubuntu.png Initializing cube options...done Initializing rotate options...done Initializing scale options...done Initializing switcher options...done /usr/bin/compiz.real (core) - Error: Plugin 'text' not loaded. /usr/bin/compiz.real (scaleaddon) - Warn: No compatible text plugin found. Initializing scaleaddon options...done Setting Update focus_effect Strange that it is so slow, because when logging in, it works fine (except for the mentioned crash). Another annoyance was that my gnome-terminal windows (which are in the gnome session) were suddenly placed elsewhere (other windows were not). -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686-bigmem (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages compiz depends on: ii compiz-core 0.8.2-6OpenGL window and compositing mana ii compiz-gnome 0.8.2-6OpenGL window and compositing mana ii compiz-gtk0.8.2-6OpenGL window and compositing mana ii compiz-plugins0.8.2-6OpenGL window and compositing mana compiz recommends no packages. Versions of packages compiz suggests: ii compizconfig-settings-manager 0.8.2-2Compizconfig Settings Manager -- no debconf information This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546419: xcursor-themes: No 'busy' cursor for e.g. whiteglass
Package: xcursor-themes Version: 1.0.1-6 Severity: normal I'm using the whiteglass cursor theme, and since the default cursor is 'oxy-black', it is very apparent that there is no cursor for 'busy'. So, e.g., when loading a web page, my beautiful whiteglass cursor becomes black with 2 revolving blobs around it (from the oxy-black theme), which looks very ugly. When the default cursor theme was still different (I don't know the name, but the busy one was a kind of rotating white circle), this wasn't that annoying, because it kind of fits in the whiteglass theme, but now it is... -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529648: compiz: Missing keyboard shortcut/hotkey for Raise or Lower
Package: compiz Version: 0.8.2-6 Severity: normal A feature which I very often use in Metacity, which I wouldn't want to miss when migrating to compiz, is the Raise or Lower short cut. This raises an obscured window when pressing the hot key, or lowers it if it's already on top. Very useful to quickly cycle through your windows. Unfortunately, it is currently not possible to create this shortcut (at least not via CompizConfig Settings Manager). Please add this feature! By the way, I found a similar request on Ubuntu's Launchpad: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/216550 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages compiz depends on: ii compiz-core 0.8.2-6OpenGL window and compositing mana ii compiz-gnome 0.8.2-6OpenGL window and compositing mana ii compiz-gtk0.8.2-6OpenGL window and compositing mana ii compiz-plugins0.8.2-6OpenGL window and compositing mana compiz recommends no packages. Versions of packages compiz suggests: ii compizconfig-settings-manager 0.8.2-1Compizconfig Settings Manager -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529397: compiz: Very very very slow on nVidia Quadro NVS 285
Package: compiz Version: 0.8.2-6 Severity: normal While other GL stuff runs fine, running compiz is unbearably slow on my nVidia Quadro NVS 285, using nVidia's proprietary drivers. See: GL_VERSION: 2.1.2 NVIDIA 173.14.09 GL_VENDOR: NVIDIA Corporation GL_RENDERER: Quadro NVS 285/PCI/SSE2 Maybe it has to do with a dual screen setup? Note: slow means that I can see windows being drawn when clicking on them to bring them forward. Many other parts of the desktop aren't drawn at all (window content, panel applets, etc.). This makes the desktop completely unusable when running compiz. I'm starting from a GNOME/Metacity session and I type: compiz --replace in a terminal to get this result. Any other info I can provide to find the cause? -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686-bigmem (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages compiz depends on: ii compiz-core 0.8.2-6OpenGL window and compositing mana ii compiz-gnome 0.8.2-6OpenGL window and compositing mana ii compiz-gtk0.8.2-6OpenGL window and compositing mana ii compiz-plugins0.8.2-6OpenGL window and compositing mana compiz recommends no packages. Versions of packages compiz suggests: ii compizconfig-settings-manager 0.8.2-1Compizconfig Settings Manager -- no debconf information This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#455750: compizconfig-settings-manager: Errors when installing
Package: compizconfig-settings-manager Version: 0.6.0-1 Severity: normal In postinst: Setting up compizconfig-settings-manager (0.6.0-1) ... Compiling /var/lib/python-support/python2.3/ccm/Conflicts.py ... File /var/lib/python-support/python2.3/ccm/Conflicts.py, line 71 settings = sum((z.values() for z in [plugin.Screens[CurrentScreenNum]]+[plugin.Display]), []) ^ SyntaxError: invalid syntax Compiling /var/lib/python-support/python2.3/ccm/Pages.py ... File /var/lib/python-support/python2.3/ccm/Pages.py, line 168 settings = sum((v.values() for v in [subGroup.Display]+[subGroup.Screens[CurrentScreenNum]]), []) ^ SyntaxError: invalid syntax Compiling /var/lib/python-support/python2.3/ccm/Settings.py ... File /var/lib/python-support/python2.3/ccm/Settings.py, line 962 settings = FilterSettings(sorted(sum((v.values() for v in [subGroup.Display]+[subGroup.Screens[CurrentScreenNum]]), []), SettingSortCompare), filter, noActions=True) ^ SyntaxError: invalid syntax That looks pretty bad. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-k7 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages compizconfig-settings-manager depends on: ii python2.4.4-6An interactive high-level object-o ii python-support0.7.5 automated rebuilding support for p Versions of packages compizconfig-settings-manager recommends: ii python-sexy 0.1.9-1python language bindings for libse -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454922: compiz: Copy settings (e.g. keyboard shortcuts) from Metacity automatically
Hi, Brice Goglin wrote: I don't think this is going to happen. Compiz and Metacity are not to similar, they are just 2 window managers that happen to be able to replace each other. This wishlist looks like asking Gnome and KDE to use the same settings... If you really want this to happen, you should talk to the upstream compiz dev and see what happens... I can try, but in Ubuntu they're also talking about this: https://wiki.ubuntu.com/DesktopTeam/Specs/HardyDesktopEffects https://wiki.ubuntu.com/CompositeByDefault Maybe we can lever on their efforts? -- Kind regards, Manuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454923: compiz-gnome: Needs GNOME configuration dialog
Package: compiz-gnome Version: 0.5.2-2 Severity: wishlist It would be useful to have a configuration dialog to configure compiz in the GNOME menu somewhere. I've seen this in Fedora (from Core 6) and in Ubuntu. At least a way to start it (Enable desktop effects). (Isn't it possible to incorporate at least the Ubuntu stuff for this?) Configuring would be even better: set up the plugins (without having to run gconf manually...) and do the settings for them. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-k7 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages compiz-gnome depends on: ii compiz-gtk 0.5.2-2 OpenGL window and compositing mana ii libart-2.0-22.3.19-3 Library of functions for 2D graphi ii libatk1.0-0 1.20.0-1 The ATK accessibility toolkit ii libbonobo2-02.20.1-1 Bonobo CORBA interfaces library ii libbonoboui2-0 2.20.0-1 The Bonobo UI library ii libc6 2.7-3GNU C Library: Shared libraries ii libcairo2 1.4.10-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.4.2-1.2generic font configuration library ii libgconf2-4 2.20.1-1 GNOME configuration database syste ii libglib2.0-02.14.3-1 The GLib library of C routines ii libgnome-desktop-2 2.20.1-1 Utility library for loading .deskt ii libgnome-keyring0 2.20.1-1 GNOME keyring services library ii libgnome-window-settings1 1:2.18.1-1 Utility library for getting window ii libgnome2-0 2.20.1.1-1 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.20.1.1-1 A powerful object-oriented display ii libgnomeui-02.20.1.1-1 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 1:2.20.1-1 GNOME Virtual File System (runtime ii libgtk2.0-0 2.12.1-1 The GTK+ graphical user interface ii libice6 2:1.0.4-1X11 Inter-Client Exchange library ii liborbit2 1:2.14.7-0.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.18.3-1 Layout and rendering of internatio ii libpopt01.10-3 lib for parsing cmdline parameters ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libstartup-notification00.9-1library for program launch feedbac ii libx11-62:1.0.3-7X11 client-side library ii libxcursor1 1:1.1.9-1X cursor management library ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2X11 miscellaneous 'fixes' extensio ii libxi6 2:1.1.3-1X11 Input extension library ii libxinerama11:1.0.2-1X11 Xinerama extension library ii libxrandr2 2:1.2.2-1X11 RandR extension library ii libxrender1 1:0.9.4-1X Rendering Extension client libra compiz-gnome recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454922: compiz: Copy settings (e.g. keyboard shortcuts) from Metacity automatically
Package: compiz Version: 0.5.2-2 Severity: wishlist When starting compiz as a replacement of Metacity, it's quite annoying that all settings (e.g. keyboard shortcuts, number of virtual desktops) are not working anymore. It would be a lot more user friendly if it were a drop in replacement, keeping the settings you're used to working. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-k7 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages compiz depends on: ii compiz-core 0.5.2-2OpenGL window and compositing mana ii compiz-gnome 0.5.2-2OpenGL window and compositing mana ii compiz-gtk0.5.2-2OpenGL window and compositing mana ii compiz-plugins0.5.2-2OpenGL window and compositing mana compiz recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454340: compiz: Documentation outdated
Package: compiz Version: 0.5.2-2 Severity: normal The documentation in /usr/share/doc/compiz/README.Debian is outdated. It starts with: compiz - 0.0.13+git20060928 === This version of compiz was checked out from the upstream git repository at git://anongit.freedesktop.org/git/xorg/app/compiz on September 28, 2006. While we're at version 0.5.2 in testing... -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-k7 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages compiz depends on: ii compiz-core 0.5.2-2OpenGL window and compositing mana ii compiz-gnome 0.5.2-2OpenGL window and compositing mana ii compiz-gtk0.5.2-2OpenGL window and compositing mana ii compiz-plugins0.5.2-2OpenGL window and compositing mana compiz recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365079: gnome-session causes X to signal 11, after xkb-data install
Package: xkb-data Version: 0.8-5 Severity: normal Hello, I do a dist-upgrade everyday, and before this one: [REMOVE, NOT USED] libresmgr1 [REMOVE, NOT USED] resmgr [INSTALL, DEPENDENCIES] xkb-data [UPGRADE] info 4.8-8 - 4.8.dfsg.1-1 [UPGRADE] liblcms1 1.13-1 - 1.15-1 [UPGRADE] liblcms1-dev 1.13-1 - 1.15-1 [UPGRADE] libxklavier10 2.2-1 - 2.2-3 [UPGRADE] texinfo 4.8-8 - 4.8.dfsg.1-1 [UPGRADE] xml-core 0.09 - 0.09-0.1 I had a perfectly working X server. After the above dist-upgrade, my X server does a signal 11 when running gnome-session. I suspect xkb-data, because it is the only related package that got installed/upgraded and because of the following backtrace that apperas in the X log: # Backtrace: # 0: /usr/bin/X11/X(xf86SigHandler+0x88) [0x8089898] # 1: [0xe420] # 2: /lib/tls/i686/cmov/libc.so.6(malloc+0x7f) [0xb7ddc92f] # 3: /usr/bin/X11/X(Xalloc+0x1b) [0x80ee7cb] # 4: /usr/bin/X11/X(Xcalloc+0x1a) [0x80ee99a] # 5: /usr/bin/X11/X [0x814c9be] # 6: /usr/bin/X11/X(SrvXkbAddGeomShape+0x127) [0x814d477] # 7: /usr/bin/X11/X(ProcXkbSetGeometry+0x477) [0x812bf67] # 8: /usr/bin/X11/X(Dispatch+0x15e) [0x80c9a7e] # 9: /usr/bin/X11/X(main+0x415) [0x80d6785] # 10: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xd0) [0xb7d88eb0] # 11: /usr/bin/X11/X [0x8070131] As you see in frame 6, there's also Xkb... Please tell me if I can further help to fix this, because it renders my whole GNOME system useless. I'm running an up-to-date testing. The problem occurs with any X driver, including VESA. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365079: Acknowledgement (gnome-session causes X to signal 11, after xkb-data install)
Hi, OK, sorry for filing a duplicate bug. The solution: downgrade libxklavier10 to 2.2-1. See bugs: 364838 and 364830 I think this bug should be reassigned to libxklavier10 (or X) and could be merged with the above bugs. I'll leave that up to the maintainer (I haven't got much experience with the BTS commands...) It is a very severe bug though! I think it only occurs if you have changed the keyboard settings in GNOME. E.g., I changed the compose key setting. I suppose that setting does something with the xkb extension, which triggers this bug. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#232390: Bug#225753: xserver-xfree86: [mga] text droppings with TrueType fonts on accelerated Matrox G450
Branden Robinson wrote: As of xserver-xfree86 4.3.0.dfsg.1-4 (or possibly earlier), this bug no longer manifests on my system. Thanks for following up, and I'm glad to hear the problem is resolved! Mr. Bilderbeek, has this problem also been resolved for you? If so, I will close these bugs. I have just tested it and I could no longer reproduce the problem, so I think it can be closed (until it possibly pops back up). And please call me Manuel :) Kind regards, -- --- Manuel Bilderbeek --- Oce-Technologies B.V. tel +31 77 3595039 St Urbanusweg 43 fax +31 77 3595337 NL-5900 MA Venlo home +31 24 3238923 The Netherlands e-mail [EMAIL PROTECTED] -
Bug#232390: libxrender1: Text end up on the wrong place with dual head
Michel Dänzer wrote: This could be #225753. Yes, it seems to be. Sorry for filing a duplicate bug. -- --- Manuel Bilderbeek --- Oce-Technologies B.V. tel +31 77 3595039 St Urbanusweg 43 fax +31 77 3595337 NL-5900 MA Venlo home +31 24 3238923 The Netherlands e-mail [EMAIL PROTECTED] -
Bug#232390: libxrender1: Text end up on the wrong place with dual head
Package: libxrender1 Version: 0.8.3-5 Severity: normal When using applications which use anti-aliased fonts (like Mozilla 1.5, gnome-terminal, etc.) I often see some texts being placed on the wrong position on the screen, outside of the window of the application! The text is not drawn where it should have been. I think it only occurs in combination with dual head systems (Xinerama), since I haven't seen this problem on my other system, which has the same software installed, but no dual head. I'd be happy to provide a screenshot for those interested. This behaviour is realy annoying! It makes my desktop look like a mess, if several texts (sometimes in very big fonts) are printed all over my desktop... Note that I'm not sure in what library the bug is, but libxrender1 was my best guess. By the way: I'm using a Matrox G450DH video card here, with the Matrox drivers. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux pc1-bilm 2.4.24-1-686 #1 Tue Jan 6 21:29:44 EST 2004 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to en_US) Versions of packages libxrender1 depends on: ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii xlibs 4.2.1-12.1 X Window System client libraries -- no debconf information
Re: Some annoying problems with ATi Radeon 7200!
Michel Dänzer wrote: On Die, 2002-11-12 at 20:41, Manuel Bilderbeek wrote: How can it be so little while having 32MB of videoRAM? The amount of memory available for textures is the total amount of video RAM minus the amount occupied by the front, back and depth buffers and the pixmap cache. In your case, approximately 32*1024*1024 - 4*1600*1200*4 But during a TuxRacer game the resolution is a lot lower... Or doesn't that make a difference? Why do almost all other GL apps work fine, even Return to Castle Wolfenstein and the Quake 3 Arena demo? I guess they need a lot more texture memory. I agree that they probably use a larger total amount of textures than tuxracer, but they may keep uploading textures and still be playable as long as there's always enough room for all the textures needed to render a single primitive... Aha. Still, that's to be expected at 1600x1200x32. You can try Option NoBackBuffer, but I doubt you'll like it. Another possibility would be running another server at a lower resolution, with Option DRIReinit you can run several servers with DRI enabled. All that to play Tuxracer? I don't believe this is the problem... And it doesn't explain the 'shocky' behaviour of that game. ... whereas this may not be true with tuxracer, which might require falling back to software rendering. RADEON_DEBUG=fall tuxracer 2/tmp/tuxracer.fallbacks should give information about that. I get all kinds of messages like this: VFMT_FALLBACK from radeon_fallback_CallList VFMT_FALLBACK_OUTSIDE_BEGIN_END from VFMT_FALLBACK radeonUploadTexImages: ran into bound texture Radeon begin tcl fallback Rasterization fallback Radeon begin rasterization fallback: 0x1 Texture mode Radeon end tcl fallback Rasterization fallback Radeon end tcl fallback Radeon end rasterization fallback: 0x1 Texture mode VFMT_FALLBACK from radeon_fallback_DrawElements VFMT_FALLBACK_OUTSIDE_BEGIN_END from VFMT_FALLBACK Radeon begin tcl fallback Texgen unit 0 Radeon end tcl fallback Texgen unit 0 Radeon end tcl fallback VFMT_FALLBACK from radeon_fallback_DrawElements VFMT_FALLBACK_OUTSIDE_BEGIN_END from VFMT_FALLBACK VFMT_FALLBACK from radeon_Materialfv Radeon begin tcl fallback Materials in VB (maybe between begin/end) Radeon end tcl fallback Materials in VB (maybe between begin/end) Radeon end tcl fallback Radeon begin tcl fallback Materials in VB (maybe between begin/end) Radeon end tcl fallback Materials in VB (maybe between begin/end) Radeon end tcl fallback VFMT_FALLBACK from radeon_fallback_CallList VFMT_FALLBACK_OUTSIDE_BEGIN_END from VFMT_FALLBACK VFMT_FALLBACK_OUTSIDE_BEGIN_END from radeonVtxfmtUnbindContext As a reminder: Tux looks perfect now, now white feet or arms anymore, the game is just shocky... Hanging X servers are really annoying, by the way... You have to reboot! True, and unfortunately it's very hard to avoid all lockups, and investigating them is highly non-trivial and time consuming. It would still be an idea to report these to the dri-devel list so the developers are aware of the problems and can try to track them down when they have time. Yeah, I understand that it's very time consuming and all. I'll put it to the list of things I have to report to DRI list. ;-) -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some annoying problems with ATi Radeon 7200!
Michel Dänzer wrote: On Die, 2002-11-12 at 20:41, Manuel Bilderbeek wrote: How can it be so little while having 32MB of videoRAM? The amount of memory available for textures is the total amount of video RAM minus the amount occupied by the front, back and depth buffers and the pixmap cache. In your case, approximately 32*1024*1024 - 4*1600*1200*4 But during a TuxRacer game the resolution is a lot lower... Or doesn't that make a difference? Why do almost all other GL apps work fine, even Return to Castle Wolfenstein and the Quake 3 Arena demo? I guess they need a lot more texture memory. I agree that they probably use a larger total amount of textures than tuxracer, but they may keep uploading textures and still be playable as long as there's always enough room for all the textures needed to render a single primitive... Aha. Still, that's to be expected at 1600x1200x32. You can try Option NoBackBuffer, but I doubt you'll like it. Another possibility would be running another server at a lower resolution, with Option DRIReinit you can run several servers with DRI enabled. All that to play Tuxracer? I don't believe this is the problem... And it doesn't explain the 'shocky' behaviour of that game. ... whereas this may not be true with tuxracer, which might require falling back to software rendering. RADEON_DEBUG=fall tuxracer 2/tmp/tuxracer.fallbacks should give information about that. I get all kinds of messages like this: VFMT_FALLBACK from radeon_fallback_CallList VFMT_FALLBACK_OUTSIDE_BEGIN_END from VFMT_FALLBACK radeonUploadTexImages: ran into bound texture Radeon begin tcl fallback Rasterization fallback Radeon begin rasterization fallback: 0x1 Texture mode Radeon end tcl fallback Rasterization fallback Radeon end tcl fallback Radeon end rasterization fallback: 0x1 Texture mode VFMT_FALLBACK from radeon_fallback_DrawElements VFMT_FALLBACK_OUTSIDE_BEGIN_END from VFMT_FALLBACK Radeon begin tcl fallback Texgen unit 0 Radeon end tcl fallback Texgen unit 0 Radeon end tcl fallback VFMT_FALLBACK from radeon_fallback_DrawElements VFMT_FALLBACK_OUTSIDE_BEGIN_END from VFMT_FALLBACK VFMT_FALLBACK from radeon_Materialfv Radeon begin tcl fallback Materials in VB (maybe between begin/end) Radeon end tcl fallback Materials in VB (maybe between begin/end) Radeon end tcl fallback Radeon begin tcl fallback Materials in VB (maybe between begin/end) Radeon end tcl fallback Materials in VB (maybe between begin/end) Radeon end tcl fallback VFMT_FALLBACK from radeon_fallback_CallList VFMT_FALLBACK_OUTSIDE_BEGIN_END from VFMT_FALLBACK VFMT_FALLBACK_OUTSIDE_BEGIN_END from radeonVtxfmtUnbindContext As a reminder: Tux looks perfect now, now white feet or arms anymore, the game is just shocky... Hanging X servers are really annoying, by the way... You have to reboot! True, and unfortunately it's very hard to avoid all lockups, and investigating them is highly non-trivial and time consuming. It would still be an idea to report these to the dri-devel list so the developers are aware of the problems and can try to track them down when they have time. Yeah, I understand that it's very time consuming and all. I'll put it to the list of things I have to report to DRI list. ;-) -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/
Re: Some annoying problems with ATi Radeon 7200!
Michel Dänzer wrote: (II) RADEON(0): Will use 2752 kb for textures at offset 0x1d5 That's very little indeed. How can it be so little while having 32MB of videoRAM? Why do almost all other GL apps work fine, even Return to Castle Wolfenstein and the Quake 3 Arena demo? I guess they need a lot more texture memory. Use a lower virtual resolution or depth, or buy a card with more RAM. ;) I have 32MB! That should be enough... (I'm doing all this on a Radeon 32MB SDR.) Still, that's to be expected at 1600x1200x32. You can try Option NoBackBuffer, but I doubt you'll like it. Another possibility would be running another server at a lower resolution, with Option DRIReinit you can run several servers with DRI enabled. All that to play Tuxracer? I don't believe this is the problem... And it doesn't explain the 'shocky' behaviour of that game. By the way, I managed to let X hang a couple of times using 3D apps: 1) I ran the molecule3D demo of xscreensaver in the root window, then I moved my 'workspace' clip of WindowMaker to the left and it hung 2) I played CannonSmash, a table tennis simulation game, and in the middle of a game it hung (the X server i.e.). Hanging X servers are really annoying, by the way... You have to reboot! (Keyboard locked...) [radeon man pages] Is the original author not finishing it then? Haven't heard from him since then. Do you want to try and contact him? Sure, why not? :-) I will, but please tell me when a new one is available, since apt-get update; apt-get upgrade now installs that 11-06 package that breaks my 3D, as I reported here. (I don't want to downgrade after every upgrade, so I disabled that deb line...) You can put it on hold to avoid getting a version that breaks for you. OK, I put xserver-xfree86-dri-trunk hold -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some annoying problems with ATi Radeon 7200!
Michel Dänzer wrote: (II) RADEON(0): Will use 2752 kb for textures at offset 0x1d5 That's very little indeed. How can it be so little while having 32MB of videoRAM? Why do almost all other GL apps work fine, even Return to Castle Wolfenstein and the Quake 3 Arena demo? I guess they need a lot more texture memory. Use a lower virtual resolution or depth, or buy a card with more RAM. ;) I have 32MB! That should be enough... (I'm doing all this on a Radeon 32MB SDR.) Still, that's to be expected at 1600x1200x32. You can try Option NoBackBuffer, but I doubt you'll like it. Another possibility would be running another server at a lower resolution, with Option DRIReinit you can run several servers with DRI enabled. All that to play Tuxracer? I don't believe this is the problem... And it doesn't explain the 'shocky' behaviour of that game. By the way, I managed to let X hang a couple of times using 3D apps: 1) I ran the molecule3D demo of xscreensaver in the root window, then I moved my 'workspace' clip of WindowMaker to the left and it hung 2) I played CannonSmash, a table tennis simulation game, and in the middle of a game it hung (the X server i.e.). Hanging X servers are really annoying, by the way... You have to reboot! (Keyboard locked...) [radeon man pages] Is the original author not finishing it then? Haven't heard from him since then. Do you want to try and contact him? Sure, why not? :-) I will, but please tell me when a new one is available, since apt-get update; apt-get upgrade now installs that 11-06 package that breaks my 3D, as I reported here. (I don't want to downgrade after every upgrade, so I disabled that deb line...) You can put it on hold to avoid getting a version that breaks for you. OK, I put xserver-xfree86-dri-trunk hold -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/
Re: Some annoying problems with ATi Radeon 7200!
Michel Dänzer wrote: - Tux's right arm is still a bit white and so is the bottom of his feet - Lots of these messages on the screen: radeonUploadTexImages: ran into bound texture Hmm, I don't see that, maybe you're still low on texture memory? grep 'for textures' /var/log/XFree86.0.log (II) RADEON(0): Will use 2752 kb for textures at offset 0x1d5 What can I do about it? Use a lower virtual resolution or depth, or buy a card with more RAM. ;) I have 32MB! That should be enough... (I'm doing all this on a Radeon 32MB SDR.) If SWcursor helps once but then again not, I don't call that 100% reproducible. If there *is* a difference, that may explain it. I can try to do this of course, but logging out and restarting X is a bit of an annoying business (since I have to look at a black screen for 10 seconds each time...) I will do it of course, if you think it's worthwile. What would you want to achieve with that? :) Reproduce the temporary fix! Thanks a lot! I hope the final version will be released soon, in one of the packages. Yes, hopefully someone picks it up, maybe you? :) What do you mean with 'picks it up'? Finishes it and pushes for its inclusion. Is the original author not finishing it then? Anyway, I hope these improved drivers will go mainstream soon, since they contain a lot less bugs than the current ones that *are* in the mainstream... They will be in 4.3.0, at least more or less. Great. :-) Just keep using my packages. :) I will, but please tell me when a new one is available, since apt-get update; apt-get upgrade now installs that 11-06 package that breaks my 3D, as I reported here. (I don't want to downgrade after every upgrade, so I disabled that deb line...) -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some annoying problems with ATi Radeon 7200!
Michel Dänzer wrote: - Tux's right arm is still a bit white and so is the bottom of his feet - Lots of these messages on the screen: radeonUploadTexImages: ran into bound texture Hmm, I don't see that, maybe you're still low on texture memory? grep 'for textures' /var/log/XFree86.0.log (II) RADEON(0): Will use 2752 kb for textures at offset 0x1d5 What can I do about it? Use a lower virtual resolution or depth, or buy a card with more RAM. ;) I have 32MB! That should be enough... (I'm doing all this on a Radeon 32MB SDR.) If SWcursor helps once but then again not, I don't call that 100% reproducible. If there *is* a difference, that may explain it. I can try to do this of course, but logging out and restarting X is a bit of an annoying business (since I have to look at a black screen for 10 seconds each time...) I will do it of course, if you think it's worthwile. What would you want to achieve with that? :) Reproduce the temporary fix! Thanks a lot! I hope the final version will be released soon, in one of the packages. Yes, hopefully someone picks it up, maybe you? :) What do you mean with 'picks it up'? Finishes it and pushes for its inclusion. Is the original author not finishing it then? Anyway, I hope these improved drivers will go mainstream soon, since they contain a lot less bugs than the current ones that *are* in the mainstream... They will be in 4.3.0, at least more or less. Great. :-) Just keep using my packages. :) I will, but please tell me when a new one is available, since apt-get update; apt-get upgrade now installs that 11-06 package that breaks my 3D, as I reported here. (I don't want to downgrade after every upgrade, so I disabled that deb line...) -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/
Re: Some annoying problems with ATi Radeon 7200!
Michel Dänzer wrote: - TuxRacer: Tux looks white! Hah! Tux looks normal now! However, still problems with Tuxracer: with the new drivers, the game slows down incredibly about every second. It seems to go smoooth, almost stops then, continues smoothly then, almost stops again, etc. In my terminal this appears: radeonUpdatePageFlipping allow 0 current 0 radeon_makeX86Normal3fv/195 CVAL 0 OFFSET 14 VAL 40763f60 radeon_makeX86Normal3fv/196 CVAL 4 OFFSET 20 VAL 40763f64 radeon_makeX86Normal3fv/197 CVAL 8 OFFSET 25 VAL 40763f68 radeon_makeX86Normal3fv done This is harmless debugging output. radeonUploadTexImages: ran into bound texture If I play for a longer time, loads of those radeonUploadTexImages messages appear A bug? Possibly, does it still occur with the latest packages, which are now available from deb http://people.debian.org/~daenzer/dri-trunk/ ./ ? First of all, there seems to be a (small?) error in the package: Setting up xserver-xfree86-dri-trunk (2002.11.06-1) ... Argument 180= isn't numeric in numeric lt () at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 25. But, huge problems when trying to run 3D apps. Simple stuff like glgears works fine, but e.g. Tuxracer and Armagetron are extremely slow and this appears on the terminal: goemon:~ armagetron radeonUploadTexImages: upload texture failure on both local and AGP texture heaps, sz=350208 radeonUploadTexImages: upload texture failure on both local and AGP texture heaps, sz=175104 and many more of similar lines. Hardware acceleration is enabled, though. I downgraded the xserver-xfree86-dri-trunk package, which solved the problem. Most debug messages are gone now (e.g. when dragging the glxgears window), but the problems with Tuxracer remain. For completeness, this is what i hvae installed now: goemon:~ dpkg -l | grep trunk rc drm-trunk-module-2.4.19 10.00.Custom+2002.10.02-1 DRI CVS trunk DRM modules ii drm-trunk-module-2.4.19-k7 10.00.Custom+2002.11.06-1 DRI CVS trunk DRM modules ii drm-trunk-module-src2002.11.06-1 Source for the DRI CVS trunk DRM modules ii xlibmesa3-dri-trunk 2002.11.06-1 DRI CVS trunk version of Mesa 3D graphics library ii xserver-xfree86-dri-trunk 2002.10.02-2 The DRI CVS trunk XFree86 X server Also, in the syslog: Nov 8 20:06:57 goemon kernel: [drm:radeon_freelist_get] *ERROR* returning NULL! This can happen intermittently without being a problem, or it can bea symptom of a lockup. It's still in the syslog when running Tuxracer. This problem is completely gone now! The game seems to work just fine! Really? I need to set RADEON_NO_VTXFMT=1 for the textures to be rendered correctly. It reallly works. ? I just logged in and the problem is back! And it's *massive*!! It's far worse than I've ever seen. Any change on the screen produces this interference now! :-( I don't understand it at all... How could it have been solved for that particular time? Weird. Definately. It seems to be a driver problem though, not a cable problem, since I once had it working... (That was, adding the option, logging out, restarting X with CTRL ALT BS and then logging in again...) Not sure what you wanna know; post to [EMAIL PROTECTED] (beware, moderated for non-subscribers) describing the problem in detail. OK. James Ralston posted it to Xpert on July 21st under the subject 'adding radeon driver documentation'. I can't seem to decode his attachment... Please e-mail that draft to me, if you have it... Thanks in advance. I have the AGP Aperture set to 64MB, or doesn't this have to do with AGPSize? It's the upper limit. The radeon driver doesn't do AGP texturing currently so it uses 3 MB of AGP memory at most. Anything more is basically wasted. OK. I'll leave it to default then. - When X is booted, the screen stays black for quite a long time. My monitor reports that the frequency is only 2Hz or so, and almost goes off. But just before it goes off, my xdm login screen appears. Is there a reason for this long delay? It's probably the driver querying the monitor via DDC. Can I make it shorter? Option NoDDC or NoVBE may help. It doesn't make any difference. With the latter, I get this in the log: (WW) RADEON(0): Option NoVBE is not used You can boot into single user mode by passing 'single' as an argument to the kernel. Ah, *that* was it... THanks! PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ Funny, my first computer was an MSX, from Canon IIRC. :) Hehhe! Probably a Canon V-20. MSX is one of my greatest hobbies. :-) -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my
Re: Some annoying problems with ATi Radeon 7200!
Michel Dänzer wrote: Hmm, might be caused by some cruft left over in the postinst. Cleaning that up for the next version. OK, I'm doing a dist-upgrade everyday, so I guess I'll see it coming then. I downgraded the xserver-xfree86-dri-trunk package, which solved the problem. Ah, this might be related to the integration of RandR support. There's a buglet which causes the server to use insane virtual resolutions, leaving no space for textures. A workaround is to explicitly set the virtual resolution in the display subsection. I'll look into integrating the fix for the next version. OK, see above. :-) Most debug messages are gone now (e.g. when dragging the glxgears window), but the problems with Tuxracer remain. What problems exactly? Note that it is slow in depth 24, and it shows some incorrect rendering unless RADEON_TCL_FORCE_DISABLE=1 is set. This doesn't really make a difference. The problems are: - Every about 0.4 seconds, the speed goes down dramatically for a short while (0.2 sec?), after which it continues normally. The first few seconds work normally though (I tried the Bunny Hill level) and also at the end things get slightly better. - Tux's right arm is still a bit white and so is the bottom of his feet - Lots of these messages on the screen: radeonUploadTexImages: ran into bound texture I tried setting the other variable you mentioned: RADEON_NO_VTXFMT=1 solves the problem of the white arm and feet of Tux, but the game speed is even jerkier than without it. Really? I need to set RADEON_NO_VTXFMT=1 for the textures to be rendered correctly. It reallly works. The problem may not be obvious if you don't have the skies enabled, but you should notice the floor texture changing when you go to the menu with Esc. You're right. I turned on the skies and I saw the problems now. Setting that RADEON_NO_VTXFMT=1 variable helps indeed! Definately. It seems to be a driver problem though, not a cable problem, since I once had it working... (That was, adding the option, logging out, restarting X with CTRL ALT BS and then logging in again...) Not so sure, I'd expect a driver problem to be 100% reproducible. Well, the problem is 100% reproducible! I just didn't try to reproduce the solution, since SWcursor made things worse afterall (after rebooting, at least.) I can't seem to decode his attachment... Please e-mail that draft to me, if you have it... Thanks in advance. Attached. Thanks a lot! I hope the final version will be released soon, in one of the packages. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some annoying problems with ATi Radeon 7200!
Michel Dänzer wrote: Hmm, might be caused by some cruft left over in the postinst. Cleaning that up for the next version. OK, I'm doing a dist-upgrade everyday, so I guess I'll see it coming then. I downgraded the xserver-xfree86-dri-trunk package, which solved the problem. Ah, this might be related to the integration of RandR support. There's a buglet which causes the server to use insane virtual resolutions, leaving no space for textures. A workaround is to explicitly set the virtual resolution in the display subsection. I'll look into integrating the fix for the next version. OK, see above. :-) Most debug messages are gone now (e.g. when dragging the glxgears window), but the problems with Tuxracer remain. What problems exactly? Note that it is slow in depth 24, and it shows some incorrect rendering unless RADEON_TCL_FORCE_DISABLE=1 is set. This doesn't really make a difference. The problems are: - Every about 0.4 seconds, the speed goes down dramatically for a short while (0.2 sec?), after which it continues normally. The first few seconds work normally though (I tried the Bunny Hill level) and also at the end things get slightly better. - Tux's right arm is still a bit white and so is the bottom of his feet - Lots of these messages on the screen: radeonUploadTexImages: ran into bound texture I tried setting the other variable you mentioned: RADEON_NO_VTXFMT=1 solves the problem of the white arm and feet of Tux, but the game speed is even jerkier than without it. Really? I need to set RADEON_NO_VTXFMT=1 for the textures to be rendered correctly. It reallly works. The problem may not be obvious if you don't have the skies enabled, but you should notice the floor texture changing when you go to the menu with Esc. You're right. I turned on the skies and I saw the problems now. Setting that RADEON_NO_VTXFMT=1 variable helps indeed! Definately. It seems to be a driver problem though, not a cable problem, since I once had it working... (That was, adding the option, logging out, restarting X with CTRL ALT BS and then logging in again...) Not so sure, I'd expect a driver problem to be 100% reproducible. Well, the problem is 100% reproducible! I just didn't try to reproduce the solution, since SWcursor made things worse afterall (after rebooting, at least.) I can't seem to decode his attachment... Please e-mail that draft to me, if you have it... Thanks in advance. Attached. Thanks a lot! I hope the final version will be released soon, in one of the packages. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/
Re: Some annoying problems with ATi Radeon 7200!
Michel Dänzer wrote: On Sam, 2002-11-09 at 18:23, Manuel Bilderbeek wrote: What problems exactly? Note that it is slow in depth 24, and it shows some incorrect rendering unless RADEON_TCL_FORCE_DISABLE=1 is set. This doesn't really make a difference. The problems are: - Every about 0.4 seconds, the speed goes down dramatically for a short while (0.2 sec?), after which it continues normally. The first few seconds work normally though (I tried the Bunny Hill level) and also at the end things get slightly better. Do you have any other X clients running that draw something at about those intervals? Or any other programs doing something, for that matter? No, nothing really. And besides, it worked before I installed your new drivers and it doesn't really occur at the beginning of a level. - Tux's right arm is still a bit white and so is the bottom of his feet - Lots of these messages on the screen: radeonUploadTexImages: ran into bound texture Hmm, I don't see that, maybe you're still low on texture memory? How can I tell? What can I do about it? Definately. It seems to be a driver problem though, not a cable problem, since I once had it working... (That was, adding the option, logging out, restarting X with CTRL ALT BS and then logging in again...) Not so sure, I'd expect a driver problem to be 100% reproducible. Well, the problem is 100% reproducible! I just didn't try to reproduce the solution, since SWcursor made things worse afterall (after rebooting, at least.) If SWcursor helps once but then again not, I don't call that 100% reproducible. I guess for X rebooting doesn't differ from logging out and pressing CTRL ALT BS? If there *is* a difference, that may explain it. I can try to do this of course, but logging out and restarting X is a bit of an annoying business (since I have to look at a black screen for 10 seconds each time...) I will do it of course, if you think it's worthwile. Thanks a lot! I hope the final version will be released soon, in one of the packages. Yes, hopefully someone picks it up, maybe you? :) What do you mean with 'picks it up'? Anyway, I hope these improved drivers will go mainstream soon, since they contain a lot less bugs than the current ones that *are* in the mainstream... Then the docs should be included, of course. :-) On Windows machines people like to update their drivers really often. I like the same for my Linux system. And the docs help me to tweak them... -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/
Re: Some annoying problems with ATi Radeon 7200!
Michel Dänzer wrote: On Don, 2002-11-07 at 22:11, Manuel Bilderbeek wrote: Michel Dänzer wrote: kernel-image-2.4.19-k7 also contains some DRM modules, use --force-overwrite . OK, I did it! And, I have 3D again! :-) Now, coming back to my previous problems (I only did a quick test though...): - TuxRacer: Tux looks white! Hah! Tux looks normal now! However, still problems with Tuxracer: with the new drivers, the game slows down incredibly about every second. It seems to go smoooth, almost stops then, continues smoothly then, almost stops again, etc. In my terminal this appears: radeonUpdatePageFlipping allow 0 current 0 radeon_makeX86Normal3fv/195 CVAL 0 OFFSET 14 VAL 40763f60 radeon_makeX86Normal3fv/196 CVAL 4 OFFSET 20 VAL 40763f64 radeon_makeX86Normal3fv/197 CVAL 8 OFFSET 25 VAL 40763f68 radeon_makeX86Normal3fv done radeonUploadTexImages: ran into bound texture radeonUploadTexImages: ran into bound texture radeonUploadTexImages: ran into bound texture radeonUploadTexImages: ran into bound texture radeonUploadTexImages: ran into bound texture radeonUploadTexImages: ran into bound texture If I play for a longer time, loads of those radeonUploadTexImages messages appear A bug? Also, in the syslog: Nov 8 20:06:57 goemon kernel: [drm:radeon_freelist_get] *ERROR* returning NULL! - Armagetron: when more than 3 players are in the game, the 'motor bikes' get partly invisible; something goes wrong with the textures. When leaving the program, I can see lots of these messages from stdout/stderr: radeonUploadTexImages: ran into bound texture and in my syslog I get: Nov 4 20:19:37 goemon kernel: [drm:radeon_freelist_get] *ERROR* returning NULL! Nov 4 20:20:08 goemon last message repeated 492 times This problem is completely gone now! The game seems to work just fine! - Return to Castle Wolfenstein: the program seems to work fine, although the framerate is quite low. However, after a short while things go wrong: bitmaps seem to get corrupted. E.g. the 'health percentage' numbers flicker and when I look at the notebook, it flickers and shows wrong bitmaps and such. Huge corruption. Also in the game menu this occurs and in the game 'world' itself, only the sky flickers sometimes. The fonts in general flicker too, showing wrong bitmaps. In other words: many, many glitches. Also here, I get this in the term I started the game in: radeonUploadTexImages: ran into bound texture This problem is also completely gone! Yippee! Something else that is new now: when I run e.g. glxgears and move the glxgears window, I get lots of these messages: radeonUpdatePageFlipping allow 0 current 0 Is this normal? It's a bit annoying... D'oh, I meant Option SWcursor of course. The device section is the right place. YES! This solves the problem! So, what could be the cause of the problem and what is the disadvantage of the SWcursor? (I guess it's slower in some way...) HW cursor is better for various reasons. I've never heard of such a problem before. You may want to report it to the Xpert list. ? I just logged in and the problem is back! And it's *massive*!! It's far worse than I've ever seen. Any change on the screen produces this interference now! :-( I don't understand it at all... How could it have been solved for that particular time? So, I commented the SWcursor out again... I'd do anything to solve this problem. Let me know how to report to the Xpert list. I never knew this was a valid option for the Driver. Is there a list of options somewhere? In the source. :) Other drivers have manpages, the radeon driver not yet unfortunately. Someone posted a draft to the Xpert list a while ago, would be nice if that would make it into 4.3.0 . Where can I find that draft? Some final questions, oh Radeon Guru! :-) - What are safe settings for AGPSize? I saw it defaults to 8. In my BIOS I have the AGP Aperture set to 64MB, or doesn't this have to do with AGPSize? - When X is booted, the screen stays black for quite a long time. My monitor reports that the frequency is only 2Hz or so, and almost goes off. But just before it goes off, my xdm login screen appears. Is there a reason for this long delay? Can I make it shorter? - I played a bit with that AGPSize, and setting it to 64MB hung my X just after starting (xdm login screen wasn't even shown yet). Since I couldn't go back to my getty terminals (keyboard didn't respond) and xdm is autostarted at boot time, the only thing I could do was login from another computer to mine to change the XF86Config-4. Is there a smarter way to do this? :-) (By the way, I first tried both AGPSize 64 and AGPFastWrite true, but both seem to have very negative effects on my X... In any case: thanks a *lot* for all your help!! Keep up the good work! -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/
Re: Some annoying problems with ATi Radeon 7200!
Michel Dänzer wrote: On Mit, 2002-11-06 at 21:17, Manuel Bilderbeek wrote: goemon:~ glxgears Radeon DRI driver: Compatibility mode for DRM driver version 1.1.1 TCL will be disabled, expect reduced performance (prefer DRM radeon.o 1.3.x or newer) disabling TCL support glxgears: radeon_ioctl.h:168: radeonAllocCmdBuf: Assertion `rmesa-dri.drmMinor = 3' failed. Abort It's still using the old DRM (radeon.o kernel module), have you installed the drm-module-trunk package you built? Ah, I found out a small problem. I'm using a prebuilt Debian kernel, so the modules ended up in the wrong directory. So, I tried again, by first specifying: export APPEND_TO_VERSION=-k7 then make-kpkg modules_image (on a fresh kernel source and drm-trunk source tree) After this: goemon:/usr/src# dpkg -i drm-trunk-module-2.4.19-k7_10.00.Custom+2002.10.02-1_i386.deb (Reading database ... 88700 files and directories currently installed.) Unpacking drm-trunk-module-2.4.19-k7 (from drm-trunk-module-2.4.19-k7_10.00.Custom+2002.10.02-1_i386.deb) ... dpkg: error processing drm-trunk-module-2.4.19-k7_10.00.Custom+2002.10.02-1_i386.deb (--install): trying to overwrite `/lib/modules/2.4.19-k7/kernel/drivers/char/drm/tdfx.o', which is also in package kernel-image-2.4.19-k7 dpkg-deb: subprocess paste killed by signal (Broken pipe) depmod: *** Unresolved symbols in /lib/modules/2.4.19-k7/kernel/drivers/char/drm/gamma.o Errors were encountered while processing: drm-trunk-module-2.4.19-k7_10.00.Custom+2002.10.02-1_i386.deb So, something goes wrong! I can't find out what, though... (No single .o file is installed...) Nevertheless, this is a bug, the compatibility code is rotting... OK, but the above should work, right? Or am I doing something wrong? D'oh, I meant Option SWcursor of course. The device section is the right place. YES! This solves the problem! So, what could be the cause of the problem and what is the disadvantage of the SWcursor? (I guess it's slower in some way...) I never knew this was a valid option for the Driver. Is there a list of options somewhere? -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some annoying problems with ATi Radeon 7200!
Michel Dänzer wrote: On Mit, 2002-11-06 at 21:17, Manuel Bilderbeek wrote: goemon:~ glxgears Radeon DRI driver: Compatibility mode for DRM driver version 1.1.1 TCL will be disabled, expect reduced performance (prefer DRM radeon.o 1.3.x or newer) disabling TCL support glxgears: radeon_ioctl.h:168: radeonAllocCmdBuf: Assertion `rmesa-dri.drmMinor = 3' failed. Abort It's still using the old DRM (radeon.o kernel module), have you installed the drm-module-trunk package you built? Ah, I found out a small problem. I'm using a prebuilt Debian kernel, so the modules ended up in the wrong directory. So, I tried again, by first specifying: export APPEND_TO_VERSION=-k7 then make-kpkg modules_image (on a fresh kernel source and drm-trunk source tree) After this: goemon:/usr/src# dpkg -i drm-trunk-module-2.4.19-k7_10.00.Custom+2002.10.02-1_i386.deb (Reading database ... 88700 files and directories currently installed.) Unpacking drm-trunk-module-2.4.19-k7 (from drm-trunk-module-2.4.19-k7_10.00.Custom+2002.10.02-1_i386.deb) ... dpkg: error processing drm-trunk-module-2.4.19-k7_10.00.Custom+2002.10.02-1_i386.deb (--install): trying to overwrite `/lib/modules/2.4.19-k7/kernel/drivers/char/drm/tdfx.o', which is also in package kernel-image-2.4.19-k7 dpkg-deb: subprocess paste killed by signal (Broken pipe) depmod: *** Unresolved symbols in /lib/modules/2.4.19-k7/kernel/drivers/char/drm/gamma.o Errors were encountered while processing: drm-trunk-module-2.4.19-k7_10.00.Custom+2002.10.02-1_i386.deb So, something goes wrong! I can't find out what, though... (No single .o file is installed...) Nevertheless, this is a bug, the compatibility code is rotting... OK, but the above should work, right? Or am I doing something wrong? D'oh, I meant Option SWcursor of course. The device section is the right place. YES! This solves the problem! So, what could be the cause of the problem and what is the disadvantage of the SWcursor? (I guess it's slower in some way...) I never knew this was a valid option for the Driver. Is there a list of options somewhere? -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/
Re: Some annoying problems with ATi Radeon 7200!
Hi again, Michel Dänzer wrote: I configed it more than one time and I can't remember that debconf asked me about FBDev... Maybe it's a low priority question, otherwise it's probably autodetected from /proc/fb . Could be, but my /proc/fb is empty. However, I have serious problems with the dri packags: I can't login anymore, there is a problem with my .xsession; from .xsession-errors: Xlib: connection to :0.0 refused by server Xlib: Protocol not supported by server xrdb: Can't open display ':0' Should I set some permissions somewhere? Also, my xdm login screen looks entirely different, but I guess that is normal... (It looks a lot more ugly, by the way... ;-) In the next version, /usr/share/doc/xserver-xfree86-dri-trunk/README.Debian will contain: * xdm: in /etc/X11/xdm/xdm-config, set DisplayManager*authorize: false Does this help? It seems to! At least, I could log in now. At first I thought I did something wrong, but the xdm login screen looks normal now, not white anymore! Anyway, there is still a big problem though, my 3D seems broken: goemon:~ glxgears Radeon DRI driver: Compatibility mode for DRM driver version 1.1.1 TCL will be disabled, expect reduced performance (prefer DRM radeon.o 1.3.x or newer) disabling TCL support glxgears: radeon_ioctl.h:168: radeonAllocCmdBuf: Assertion `rmesa-dri.drmMinor = 3' failed. Abort The XFree86.0.log seems just fine. (Yep, it starts with XFree86 Version 4.2.0 (DRI trunk) / X Window System !) There are no errors there. By the way, I saw this: (II) RADEON(0): AGP Fast Write disabled by default What is AGP Fast Write? I saw in my BIOS an option to turn this on. Is this useful? One very good thing: it seems that the ghosting is a bit less now! I couldn't test with openGL programs (which caused the worst ghosting effects), but it seems that it is a bit less now... (dragging windows around is still causing some of the ghosting though...)) How can I tell what depth? xdpyinfo|grep 'depth of root' It's 24 planes. BTW, I just recall experiencing color problems on the 7200 in the gf's Cube. Seems to be a radeonfb glitch which happens intermittently and randomly. Well, I don't need fb anyway. I don't see anything unusual in the log. Does Option HWcursor make the problem go away? Do I have to put that in the driver section? I did so, but: (II) RADEON(0): Using hardware cursor (scanline 4808) (WW) RADEON(0): Option HWcursor is not used According to my XFree86 log. Note that the first line was also already in my original log, with the 4.2.1. drivers from Debian. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/
Re: Some annoying problems with ATi Radeon 7200!
Hi, Michel Dänzer wrote: I'm running X at 1600x1200x32@85Hz. My XFree86-4 is config'ed with debconf (except that I removed the Use FBdev stuff that is put there by default). I don't think it is unless you told it to. I configed it more than one time and I can't remember that debconf asked me about FBDev... http://dri.sourceforge.net/snapshots/README.Debian should be interesting for this. The driver performs much better now, and while there are still some problems, most of them can be avoided by setting certain environment variables. How exactly should I build the drm package? I'd like to use debian/rules, but I am not very familiar with this... Please tell me what I should type. Hmmm, OK, I installed kernel-package and read the README.modules. Then I typed: sudo make-kpkg modules_image cd .. sudo dpkg -i drm-trunk-module-2.4.19_10.00.Custom+2002.10.02-1_i386.deb And it got installed. However, I have serious problems with the dri packags: I can't login anymore, there is a problem with my .xsession; from .xsession-errors: Xlib: connection to :0.0 refused by server Xlib: Protocol not supported by server xrdb: Can't open display ':0' Should I set some permissions somewhere? Also, my xdm login screen looks entirely different, but I guess that is normal... (It looks a lot more ugly, by the way... ;-) Problem 3: == /etc/X11/XF86Config-4. I also tried to keep it in and load the radeonfb module, but that gave some problems: - the colors where all wrong in X What depth? radeonfb used to be broken in depth 16. How can I tell what depth? I guess it took the default depth from the XF86Config-4: 24 bpp. - in textmode the 'image' was shifted to the left, off the monitor's screen (without the fb it fits nicely) You can change the mode with fbset. Aha. So, I hope I have described my problems clearly enough. I think I'd better not put my config- and log files here, but in case you need them to help me: please ask me! I will send you anything you need. :-) Could you put them up somewhere on the web? OK, I put them here: http://manuel.msxnet.org/Xlogconfig.tar.gz Best regards, Manuel Bilderbeek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some annoying problems with ATi Radeon 7200!
Branden wrote: I don't think it is the cable, since: 1) I used the original cable that came with my Iyama A902MT monitor, which is brand new 2) the problem only occurs in X, not in textmode or in Windows (sorry for that) Those don't necessarily rule out signal degradation. 1) Iiyama may have given you a lousy cable; 2) Windows may not be cranking the signal as hard, and textmode almost certainly isn't. Ghosting is less of a problem at lower pixel clocks. I don't know enough about field effects and signal stuff to know exactly why, but this has been my experience. How can you explain then that the distortion only occurs when the X *cursor* is visible? There is no distortion in full-screen applications where the cursor is hidden! Also, when I run e.g. glxgears, I see the distortion always, except when the cursor is hidden when it is in a window that hides the cursor...! Best regards, Manuel Bilderbeek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some annoying problems with ATi Radeon 7200!
Hi, Michel Dänzer wrote: I'm running X at [EMAIL PROTECTED] My XFree86-4 is config'ed with debconf (except that I removed the Use FBdev stuff that is put there by default). I don't think it is unless you told it to. I configed it more than one time and I can't remember that debconf asked me about FBDev... http://dri.sourceforge.net/snapshots/README.Debian should be interesting for this. The driver performs much better now, and while there are still some problems, most of them can be avoided by setting certain environment variables. How exactly should I build the drm package? I'd like to use debian/rules, but I am not very familiar with this... Please tell me what I should type. Hmmm, OK, I installed kernel-package and read the README.modules. Then I typed: sudo make-kpkg modules_image cd .. sudo dpkg -i drm-trunk-module-2.4.19_10.00.Custom+2002.10.02-1_i386.deb And it got installed. However, I have serious problems with the dri packags: I can't login anymore, there is a problem with my .xsession; from .xsession-errors: Xlib: connection to :0.0 refused by server Xlib: Protocol not supported by server xrdb: Can't open display ':0' Should I set some permissions somewhere? Also, my xdm login screen looks entirely different, but I guess that is normal... (It looks a lot more ugly, by the way... ;-) Problem 3: == /etc/X11/XF86Config-4. I also tried to keep it in and load the radeonfb module, but that gave some problems: - the colors where all wrong in X What depth? radeonfb used to be broken in depth 16. How can I tell what depth? I guess it took the default depth from the XF86Config-4: 24 bpp. - in textmode the 'image' was shifted to the left, off the monitor's screen (without the fb it fits nicely) You can change the mode with fbset. Aha. So, I hope I have described my problems clearly enough. I think I'd better not put my config- and log files here, but in case you need them to help me: please ask me! I will send you anything you need. :-) Could you put them up somewhere on the web? OK, I put them here: http://manuel.msxnet.org/Xlogconfig.tar.gz Best regards, Manuel Bilderbeek
Re: Some annoying problems with ATi Radeon 7200!
Branden wrote: I don't think it is the cable, since: 1) I used the original cable that came with my Iyama A902MT monitor, which is brand new 2) the problem only occurs in X, not in textmode or in Windows (sorry for that) Those don't necessarily rule out signal degradation. 1) Iiyama may have given you a lousy cable; 2) Windows may not be cranking the signal as hard, and textmode almost certainly isn't. Ghosting is less of a problem at lower pixel clocks. I don't know enough about field effects and signal stuff to know exactly why, but this has been my experience. How can you explain then that the distortion only occurs when the X *cursor* is visible? There is no distortion in full-screen applications where the cursor is hidden! Also, when I run e.g. glxgears, I see the distortion always, except when the cursor is hidden when it is in a window that hides the cursor...! Best regards, Manuel Bilderbeek
Re: Some annoying problems with ATi Radeon 7200!
Blars Blarson wrote: In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: [ghosting] This is usually caused by a problem with your monitor or the cable to it. If you can, try a different (shorter and/or higher quality) cable. If you are using a switch box, try without. This problem may be more pronounced at some colors than others, so changing backgrounds may cause it to be less noticable. I don't think it is the cable, since: 1) I used the original cable that came with my Iyama A902MT monitor, which is brand new 2) the problem only occurs in X, not in textmode or in Windows (sorry for that) Note that it seems very related to the cursor position! (See original posting...) I can't explain that if the cable would be the problem. Thanks for your reply, though! Best regards, Manuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some annoying problems with ATi Radeon 7200!
Stephen Depooter wrote: On Mon, 2002-11-04 at 14:38, Manuel Bilderbeek wrote: Problem 2: == This is regarding 3D. The 3D acceleration seems to work fine, but there are minor problems: - TuxRacer: Tux looks white! Something is wrong with the colors of the Tux character in this game, only the shadows on the poor penguin's body is shown. I have seen it work perfectly on other computers (with some nvidia card). I had a very similar problem (possibly the same, its been a while) with a Radeon 7200 64 MB DDR AGP card. It seemed to get fixed for me though with the 4.2.1-3 packages. Which version of the x packages are you using? Exactly those: goemon:~ dpkg -l | grep xfree ii xfree86-common 4.2.1-3X Window System (XFree86) infrastructure ii xserver-xfree8 4.2.1-3the XFree86 X server :-( Best regards, Manuel Bilderbeek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Some annoying problems with ATi Radeon 7200!
Hi! Since I bought my computer and installed Debian, I have been experiencing some weird problems in X... I hope this is the right mailinglist to post this to I hoped XFree86 4.2.1 would solve some of them, but my hope was in vain: nothing changed after upgrading my 4.1.0 to 4.2.1 yesterday. I'm running testing (always upgraded to the newest packages). I have an Athlon XP 1600+ with VIA K7T266 Pro 2 mainboard and an ATI Radeon SDR 32MB AGP videocard (I think that is now called the Radeon 7200). I'm running X at [EMAIL PROTECTED] My XFree86-4 is config'ed with debconf (except that I removed the Use FBdev stuff that is put there by default). The kernel is 2.4.19. Problem 1: == Whenever there is 'movement'/'action' on the screen (e.g. an openGL demo from xscreensaver, an animation in Mozilla or a scrolling window) and the cursor is on a screenline where such action is taking place, the right side of the screen (only *right* from the cursor, about 600 pixels to the right, i.e.) shows sort of 'ghost images': parts of the moving parts *left* of the cursor are shown on the right side (shifted to the right about 510 pixels), flickering (there seem to be chunks of 32 pixels in that flickering area), but only around the Y position of the cursor (in vertical direction the flickering stuff is having a height of about 64 pixels). When the screen action stops, the effect is gone (I can't take a screenshot of it...) Changing the screen resolution doesn't affect the problem. Does anyone have an idea what's going on and how I can stop it? It's really annoying! Problem 2: == This is regarding 3D. The 3D acceleration seems to work fine, but there are minor problems: - TuxRacer: Tux looks white! Something is wrong with the colors of the Tux character in this game, only the shadows on the poor penguin's body is shown. I have seen it work perfectly on other computers (with some nvidia card). - Armagetron: when more than 3 players are in the game, the 'motor bikes' get partly invisible; something goes wrong with the textures. When leaving the program, I can see lots of these messages from stdout/stderr: radeonUploadTexImages: ran into bound texture and in my syslog I get: Nov 4 20:19:37 goemon kernel: [drm:radeon_freelist_get] *ERROR* returning NULL! Nov 4 20:20:08 goemon last message repeated 492 times - Return to Castle Wolfenstein: the program seems to work fine, although the framerate is quite low. However, after a short while things go wrong: bitmaps seem to get corrupted. E.g. the 'health percentage' numbers flicker and when I look at the notebook, it flickers and shows wrong bitmaps and such. Huge corruption. Also in the game menu this occurs and in the game 'world' itself, only the sky flickers sometimes. The fonts in general flicker too, showing wrong bitmaps. In other words: many, many glitches. Also here, I get this in the term I started the game in: radeonUploadTexImages: ran into bound texture Seems there is something going wrong, but what? Problem 3: == This is not really a problem, but I'd like to report it anyway. As I said above, I had to remove the UseFBDev option from my /etc/X11/XF86Config-4. I also tried to keep it in and load the radeonfb module, but that gave some problems: - the colors where all wrong in X - in textmode the 'image' was shifted to the left, off the monitor's screen (without the fb it fits nicely) - I tried Return to Castle Wolfenstein, but the switch to full screen went wrong and the intro demo started to play on my X desktop background (on a lower resolution) Because of this, I quickly disabled the FB stuff... So, it's not really a problem, unless you really want to use the fb! I guess it should work, though! So, I hope I have described my problems clearly enough. I think I'd better not put my config- and log files here, but in case you need them to help me: please ask me! I will send you anything you need. :-) Also, if you have suggestions what a better place for these questions would be: please let me know. (Maybe file a bug report somewhere?) Finally: - please Cc: any reactions to [EMAIL PROTECTED], since I'm not subscribed to this mailing list. - thanks to everyone in advance for any help! - thanks to Branden and all the others for their great work on the X packages! Best regards, Manuel Bilderbeek
Re: Some annoying problems with ATi Radeon 7200!
Blars Blarson wrote: In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: [ghosting] This is usually caused by a problem with your monitor or the cable to it. If you can, try a different (shorter and/or higher quality) cable. If you are using a switch box, try without. This problem may be more pronounced at some colors than others, so changing backgrounds may cause it to be less noticable. I don't think it is the cable, since: 1) I used the original cable that came with my Iyama A902MT monitor, which is brand new 2) the problem only occurs in X, not in textmode or in Windows (sorry for that) Note that it seems very related to the cursor position! (See original posting...) I can't explain that if the cable would be the problem. Thanks for your reply, though! Best regards, Manuel
Re: Some annoying problems with ATi Radeon 7200!
Stephen Depooter wrote: On Mon, 2002-11-04 at 14:38, Manuel Bilderbeek wrote: Problem 2: == This is regarding 3D. The 3D acceleration seems to work fine, but there are minor problems: - TuxRacer: Tux looks white! Something is wrong with the colors of the Tux character in this game, only the shadows on the poor penguin's body is shown. I have seen it work perfectly on other computers (with some nvidia card). I had a very similar problem (possibly the same, its been a while) with a Radeon 7200 64 MB DDR AGP card. It seemed to get fixed for me though with the 4.2.1-3 packages. Which version of the x packages are you using? Exactly those: goemon:~ dpkg -l | grep xfree ii xfree86-common 4.2.1-3X Window System (XFree86) infrastructure ii xserver-xfree8 4.2.1-3the XFree86 X server :-( Best regards, Manuel Bilderbeek
X with i810 on 1280x1024 (Was: Bug in Xgalaga?)
Hi, Still no luck, but now I inserted a ModeLine of a collegue and got this result: No mode of this name See the Config and Logfile: # XF86Config-4 (XFree86 server configuration file) generated by Dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config manual page. # (Type man XF86Config at the shell prompt.) Section Files FontPath unix/:7100 # local font server # if the local font server has problems, we can fall back on these FontPath /usr/lib/X11/fonts/misc FontPath /usr/lib/X11/fonts/cyrillic FontPath /usr/lib/X11/fonts/100dpi/:unscaled FontPath /usr/lib/X11/fonts/75dpi/:unscaled FontPath /usr/lib/X11/fonts/Type1 FontPath /usr/lib/X11/fonts/Speedo FontPath /usr/lib/X11/fonts/100dpi FontPath /usr/lib/X11/fonts/75dpi EndSection Section ServerFlags EndSection Section Module Load ddc Load GLcore Load dbe Load dri Load extmod Load glx Load pex5 Load record Load xie Load bitmap Load freetype Load speedo Load type1 Load vbe Load int10 EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device /dev/psaux Option Protocol PS/2 Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section InputDevice Identifier Generic Mouse Driver mouse Option SendCoreEvents true Option Device /dev/input/mice Option Protocol ImPS/2 Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section Device Identifier Intel i810E Driver i810 VideoRam 4096 EndSection Section Monitor Identifier Eizo HorizSync 30-96 VertRefresh 50-160 Option DPMS ModeLine 1280x1024 135.00 1280 1312 1416 1664 1024 1027 1030 1064 # Previous ModeLine was taken over from a collegue with similar hardware # ModeLine 1280x1024 108.0 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync # ModeLine 1280x1024 136.0 1280 1296 1340 1416 1024 1025 1028 1066 +hsync +vsync # ModeLine 1280x1024 157.5 1280 1344 1504 1728 1024 1025 1028 1072 +hsync +vsync EndSection Section Screen Identifier Default Screen Device Intel i810E Monitor Eizo DefaultDepth 24 Subsection Display Depth 8 Modes 1280x1024 1024x768 800x600 640x480 ViewPort0 0 EndSubsection Subsection Display Depth 16 Modes 1280x1024 ViewPort0 0 EndSubsection Subsection Display Depth 24 Modes 1280x1024 ViewPort0 0 EndSubsection Subsection Display Depth 32 Modes 1280x1024 ViewPort0 0 EndSubsection EndSection Section ServerLayout Identifier Default Layout Screen Default Screen InputDevice Generic Keyboard InputDevice Configured Mouse InputDevice Generic Mouse EndSection Section DRI Mode 0666 EndSection # end of XF86Config - XFree86 Version 4.0.3 / X Window System (protocol Version 11, revision 0, vendor release 6400) Release Date: 16 March 2001 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/FAQ) Operating System: Linux 2.2.19 i686 [ELF] Module Loader present (==) Log file: /var/log/XFree86.0.log, Time: Wed Aug 1 09:55:08 2001 (==) Using config file: /etc/X11/XF86Config-4 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (??) unknown. (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor Eizo (**) | |--Device Intel i810E (**) |--Input Device Generic Keyboard (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc104 (**) XKB: model: pc104 (**) Option XkbLayout us (**) XKB: layout: us (**) |--Input Device Configured Mouse (**) |--Input Device Generic Mouse (**) FontPath set to unix/:7100,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/cyrillic,/usr/lib/X11 /fonts/100dpi/:unscaled,/usr/lib/X11/fonts/75dpi/:unscaled,/usr/lib/X11/font s/Type1,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fon ts/75dpi (==) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (--) using VT number 7 (WW) Cannot open APM (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.3 XFree86 XInput driver : 0.1 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.2 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.0.3, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.2 (II) Loading font
Re: Bug in Xgalaga?
Hi people, Yesterday I installed kernel 2.4.6 (I used 2.2.17) and now Xgalaga does NOT crash anymore! Also, a problem I had with XMMS (it did some fast-forwarding, irratically) seems to be solved now. An other problem with sound is the following: I only get sound when I do this: rmmod i810_audio modprobe i810_audio If I don't do this, I don't get errors, but I can't hear any sound... With the previous kernel I had something similar, but then I got an error (no such device) when playing with mpg123 for example. This was also solved by removing and installing the module. About X, I still can't get X to run on 1280x1024. In the XF86Config-4, I deleted almost all modes, except 1280x1024 and it STILL switches to 1024x768. It should be possible to use that mode though (it works in Win2k too (dual boot machine) and I have collegues with the same kind of hardware (intel i810E chipset) on which it also works). As Branden requested I am adding the contents of the requested files on the bottom of this e-mail. Grtjs, Manuel PS: MSX 4 ever! (Questions? FAQ: http://www.faq.msxnet.org/ ) PPS: Visit my homepage: http://bilderbeek.cjb.net/ - Original Message - From: Branden Robinson [EMAIL PROTECTED] To: debian-x@lists.debian.org; [EMAIL PROTECTED] Sent: Tuesday, July 24, 2001 4:19 PM Subject: Re: Bug in Xgalaga? On Tue, Jul 24, 2001 at 10:00:51AM +0200, Manuel Bilderbeek wrote: Well that's pretty suprising -- xgalaga is just a plain jane X app, and Well, it's probably not *truly* plain jane, it probably uses some protocol extensions. :) it should not be able to hang the X server. This probably points to a bug in the X server or perhaps a hardware problem with your system. Perhaps the people on this list can help.. Could be, I had some very troubling troubles getting X running. In fact, this was the reason I moved to Woody. I have an onboard Intel i810 chipset and I couldn't get Potato to work with it. So now I am running Xfree86 4.0.1 with the i810 module. Maybe a bug in it, indeed? ANother problem is that I can't get it to work on 1280x1024... The X server insists on going to 1024x768 ARGH... Does anyone have any hints to get this working? If so, please mail me privately, I'm not subscribed to the mailinglist. Please email debian-user@lists.debian.org with the contents of the following files: /etc/X11/XF86Config-4 /var/log/XFree86.0.log -- HERE COME THE FILES: -- # XF86Config-4 (XFree86 server configuration file) generated by Dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config manual page. # (Type man XF86Config at the shell prompt.) Section Files FontPath unix/:7100 # local font server # if the local font server has problems, we can fall back on these FontPath /usr/lib/X11/fonts/misc FontPath /usr/lib/X11/fonts/cyrillic FontPath /usr/lib/X11/fonts/100dpi/:unscaled FontPath /usr/lib/X11/fonts/75dpi/:unscaled FontPath /usr/lib/X11/fonts/Type1 FontPath /usr/lib/X11/fonts/Speedo FontPath /usr/lib/X11/fonts/100dpi FontPath /usr/lib/X11/fonts/75dpi EndSection Section ServerFlags EndSection Section Module Load ddc Load GLcore Load dbe Load dri Load extmod Load glx Load pex5 Load record Load xie Load bitmap Load freetype Load speedo Load type1 Load vbe Load int10 EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device /dev/psaux Option Protocol PS/2 Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section InputDevice Identifier Generic Mouse Driver mouse Option SendCoreEvents true Option Device /dev/input/mice Option Protocol ImPS/2 Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section Device Identifier Intel i810E Driver i810 VideoRam 4096 EndSection Section Monitor Identifier Eizo HorizSync 30-96 VertRefresh 50-160 Option DPMS EndSection Section Screen Identifier Default Screen Device Intel i810E Monitor Eizo DefaultDepth 24 Subsection Display Depth 8 Modes 640x480 800x600 1024x768 1280x1024 ViewPort0 0 EndSubsection Subsection Display Depth 16 Modes 1280x1024 ViewPort0 0 EndSubsection Subsection Display Depth 24 Modes 1280x1024 ViewPort0 0 EndSubsection Subsection Display Depth 32 Modes 640x480 800x600 1024x768 ViewPort0 0 EndSubsection EndSection Section ServerLayout Identifier Default Layout Screen Default Screen InputDevice Generic Keyboard InputDevice Configured Mouse InputDevice Generic
Re: Bug in Xgalaga?
Manuel Bilderbeek wrote: I recently installed Debian Woody and when I was playing in X a bit, I selected Xgalaga in the WindowMaker standard menu. That crashed the pc! Is there some bug in it? Starting xgalaga from the command line does the same. Complete hangup. Well that's pretty suprising -- xgalaga is just a plain jane X app, and it should not be able to hang the X server. This probably points to a bug in the X server or perhaps a hardware problem with your system. Perhaps the people on this list can help.. Could be, I had some very troubling troubles getting X running. In fact, this was the reason I moved to Woody. I have an onboard Intel i810 chipset and I couldn't get Potato to work with it. So now I am running Xfree86 4.0.1 with the i810 module. Maybe a bug in it, indeed? ANother problem is that I can't get it to work on 1280x1024... The X server insists on going to 1024x768 ARGH... Does anyone have any hints to get this working? If so, please mail me privately, I'm not subscribed to the mailinglist. Best regards, Manuel Bilderbeek - a Newbian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
