Bug#567793: your mail
On Saturday 26 February 2011 12:29:37 you wrote: > is it going better in squeeze or sid? I just switched to 24BPP and EXA, and the artifacts are still there. Switching to XAA fixes the issues again. The version of xserver-xorg-video-radeon is 1:6.13.1-2+squeeze1. Uli -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103080645.38779.dooms...@knuut.de
Bug#587999: turning off radeonfb crashes system on console switch
Hi! I got around to testing with "video=radeonfb:off" on the kernel commandline. What you then get is a completely hanging system when switching terminale (chvt), when trying to stop the login manager KDM or when logging out of an X session. Note that this means that rebooting the system becomes impossible, similarly partitions aren't unmounted properly either. I also tried activating KMS explicitly then, but that crashes even earlier during boot, even before init is started. The kernel seems to detect that my video card has 256MiB of VRAM, while it only has 32. Some other memory layouts it detects are similarly off. If I find a free hour I'll try to disable KDM and then try without radeonfb, if that is broken, too, or if it is only in combination with X. I'll also try to copy the kernel output when using KMS. Cheers! Uli -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007191539.37722.dooms...@knuut.de
Bug#567793: EXA causes arifacts
On Sunday 11 July 2010 10:12:23 Brice.Goglin wrote: > On Sun, Jan 31, 2010 at 02:14:33PM +0100, Ulrich Eckhardt wrote: > > I have artifacts with colors being off and sometimes areas being filled > > with black/white noise. [...] > Assuming this is the problem you referred to at the end of > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587999#66 > could you give an update to the status of this exact bug report too? No, the artifacts that prompted me to file this bug were different. However, I'll give EXA another try with the new driver and report the current state. Uli -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007111349.06045.dooms...@knuut.de
Bug#587999: further info
On Sunday 11 July 2010 10:05:08 Brice Goglin wrote: > What about the original problem (pixel columns switched when using XV, > with 16 or 24 bits color depth), is it gone now? No, not really, but it doesn't affect me now. If I understand correctly, what happened was that KMS broke DRI for X, so it switched back to non-accelerated rendering. Non-accelerated rendering gets the pixel columns wrong. In addition, it seems that DRI with 24BPP requires more memory now that I have (can someone confirm/explain that?), which made diagnosis more complicated. After turning off KMS and upgrading, I was to switch back to 16BPP, which works accelerated now, so the bug doesn't affect me. However, this is rather a workaround than a fix. Uli -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007111343.34107.dooms...@knuut.de
Bug#587999: further info
On Friday 09 July 2010 17:49:57 Michel Dänzer wrote: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565313 > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567616 > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567793 > > The depth 16 issue could be fixed in xserver-xorg-video-radeon > 1:6.13.1-1, not sure about the other EXA issue. Thanks, that seems to do the job. I downloaded 6.13.1-1 from unstable and now I can again use 16 BPP without the greenish tint. Further, if I deactivate KMS (modprobe radeon modeset=0), X also initialises DRI (even though it complains about this and that) and bug 587999 doesn't appear, so it's indeed only the non-DRI code it seems. Just for the record, I had the effect that areas were not recognized as newly exposed with EXA and the new radeon driver, though only with a KDE app. Switching back to XAA seems to work around that. I'll try to reproduce this and file a separate report if I get to it. Thank you for your help, I owe you a beer! Uli -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007101731.21585.dooms...@knuut.de
Bug#587999: further info
On Friday 09 July 2010 14:56:39 Michel Dänzer wrote: > This is the reason for the DRI being disabled now: > > (II) RADEON(0): Memory manager initialized to (0,0) (1728,4854) > > (II) RADEON(0): Reserved area from (0,1680) to (1728,1682) > > (II) RADEON(0): Largest offscreen area available: 1728 x 3172 > > (II) RADEON(0): Will use front buffer at offset 0x0 > > (II) RADEON(0): Will use back buffer at offset 0x9cf000 > > (II) RADEON(0): Will use depth buffer at offset 0x14e2000 > > (II) RADEON(0): Will use 0 kb for textures at offset 0x1ff5000 > > (EE) RADEON(0): Static buffer allocation failed. Disabling DRI. > > (EE) RADEON(0): At least 34020 kB of video memory needed at this > > resolution and depth. > > Maybe it'll work without Option "AccelMethod" "XAA" I'll try that. > (or with explicit "EXA" instead), otherwise you'll need to > reduce the maximum desktop size via the Virtual directive or > run in depth 16. EXA and 16 BPP are out, except if using neither of EXA and XAA changes anything there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565313 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567616 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567793 Hopefully... Uli -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007091740.52965.dooms...@knuut.de
Bug#587999: further info
On Monday 05 July 2010 09:03:53 you wrote: > On Sam, 2010-07-03 at 23:58 +0200, Ulrich Eckhardt wrote: > > (EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM > > [dri] Disabling DRI. > > It should work better with the DRI enabled. Good catch, but shouldn't it work even without DRI? > Do you have the firmware-linux package installed? Yes. > If so, please post the output of running > > sudo modprobe radeon > > as well as the messages appearing in the dmesg output after it. The module is already loaded. I can unload it though, even with a running X11 session, "lsmod" shows that its refcount is zero. When loading it, it outputs "[drm] radeon kernel modesetting enabled." in dmesg. However, when starting the X server, it outputs "radeonfb :00:10.0: Invalid ROM contents" there. Note that this error is nothing new. X11 has been complaining about a missing ROM since I got this machine (MacMini), but has always worked nonetheless. If I understand correctly, the graphics adapter doesn't have a ROM and doesn't need one, because it is initialized by the firmware. Thanks for your effort! Uli -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007052314.06750.dooms...@knuut.de
Bug#587999: further info
-- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 Dec 10 2007 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 1940408 Jun 3 18:28 /usr/bin/Xorg /var/lib/x11/xorg.conf.roster does not exist. VGA-compatible devices on PCI bus: :00:10.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01) /var/lib/x11/xorg.conf.md5sum does not exist. Xorg X server configuration file status: -rw-r--r-- 1 root root 6148 Jul 3 16:47 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # This configfile demonstrates the broken behaviour of xorg # The problem is that this file as configuration is capable of starting X in # the configured layout, but once shut down, this does _not_ work a second # time. # # Note: # Option "UseFBDev" "true" # will enable startup. # # Configuration: # xserver-xorg-video-ati 6.6.3-2 # Monitor: # SyncMaster 225BW on VGA # Machine: # Mac Mini PPC Section "Files" FontPath"/usr/share/fonts/X11/misc" FontPath"/usr/X11R6/lib/X11/fonts/misc" FontPath"/usr/share/fonts/X11/cyrillic" FontPath"/usr/X11R6/lib/X11/fonts/cyrillic" FontPath"/usr/share/fonts/X11/100dpi/:unscaled" FontPath"/usr/X11R6/lib/X11/fonts/100dpi/:unscaled" FontPath"/usr/share/fonts/X11/75dpi/:unscaled" FontPath"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/share/fonts/X11/Type1" FontPath"/usr/X11R6/lib/X11/fonts/Type1" FontPath"/usr/share/fonts/X11/100dpi" FontPath"/usr/X11R6/lib/X11/fonts/100dpi" FontPath"/usr/share/fonts/X11/75dpi" FontPath"/usr/X11R6/lib/X11/fonts/75dpi" # path to defoma fonts FontPath"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" EndSection Section "Module" Load"bitmap" Load"dbe" Load"ddc" Load"dri" Load"extmod" #Load "freetype" Load"glx" Load"int10" Load"vbe" EndSection #Section "Extensions" #Option "Composite" "enable" #EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc104" Option "XkbLayout" "dvorak" Option "XkbVariant""dvorak" Option "XkbOptions""lv3:ralt_switch" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/input/mice" EndSection Section "Device" Identifier "Builtin Radeon" Driver "radeon" # select model with integrated DVI adapter Option "MacModel" "mini-internal" # Option "MonitorLayout" "TMDS,NULL" # Option "PanelSize" "1680x1050" # ignore monitor mode lines received via DDC but use DDC to detect the monitor itself Option "IgnoreEDID" "true" # dynamically scale the chip clock to reduce energy consumption #Option "DynamicClocks" "true" # TODO: try this on # Option "DefaultTMDSPLL" "true" # Option "AGPMode" "4" #Option "XAANoOffscreenPixmaps" "true" # Option "UseFBDev" "false" # Option "UseFBDev" "true" # Option "AGPFastWrite" "off" # Option "DDCMode" "true" # Option "AccelMethod" "EXA" # Option "AccelMethod" "XAA" # Option "ReverseDDC""true" ### # BusID "PCI:0:16:0" # All options supported by the driver (2008-08-24) # #Option "SWcursor" "boolean" #Option "SWcursor" "true" #Option "NoAccel" "boolean" #Option "Dac6Bit" "boolean" #Option "VideoKey" "integer" #Option "ScalerWidth" "integer" #Option "AGPMode" "integer" #Option "AGPFastWrite" "boolean" #Option "BusType" "string" #Option "DDCMode" "boolean" #Option "DisplayPriority" "string" #Option "ColorTiling" "boolean" #Option "IgnoreEDID" "boolean" #Option "PanelSize" "string" #Option "EnablePageFlip" "boolean" #Option "ForceMinDotClock" "frequency" #Option "RenderAccel" "boolean" #Option "AccelMethod" "string" # old X accel Option "AccelMethod" "XAA" # new X accel #Option "AccelMethod" "EXA" #Option "AccelDFS" "boolean" #Option "FBTexPercent" "integer" #Option "DepthBits" "integer" #Option "DMAForXv" "boolean" #Option "SubPixelOrder" "string" #Option "DynamicClocks" "boolean" #Option "VGAAccess" "boolean" #Option "ReverseDDC" "boolean" #Option "LVDSProbePLL" "boolea
Bug#587999: Xv switches pixel columns
Package: xserver-xorg Version: 1:7.5+6 Using mplayer and xine (didn't try others) with Xv as video output driver, I have the effect that the order of pixel columns is switched. If I use 24 bits color depth, the order is 1,0,3,2 etc. Using 16 bits color depth, the order is 3,2,1,0,7,6,5,4. Notes: * I'm using the radeon driver backend. * I'm on a big-endian machine (PPC). As a workaround, I can use xshm as video output driver. Cheers! Uli -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007032122.17560.dooms...@knuut.de
Bug#567616: Duplicate bug report?
Hi! I think that "16 bit colour on M64 gives green tinted screen" http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565313 "new update has problem using DefaultDepth 16 in xorgs config" http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567616 actually describe the same problem. Uli -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532616: Translation...
The title would translate to "nv > nvidia driver: refresh rate from 60 to 50". "mein Problem: die Wiederholrate wird beim nv-Treiber auf 60Hz gesetzt und bei dem nvidia-Treiber auf 50Hz gesetzt. das führt dazu, das die Zeichen plötzlich verdoppelt werden." My problem: The refresh rate is set to 60Hz with the 'nv' driver and to 50Hz with the 'nvidia' driver. This leads to the characters suddenly being doubled. For the record, I can't tell what the reporter actually meant with "characters being doubled", the description isn't clear in German either. HTH Uli -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567616: Some more info...
Hi! Since an update yesterday (I'm running testing here), I'm seeing the same effect here. I can also work around this by switching to 24 bits color depth. Anyway, some info on this system here: - Mac Mini with a G4 PowerPC CPU - Radeon graphics chip, 'lspci' says "VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01)" - Some installed packages: xserver-xorg1:7.5+2 xserver-xorg-core 2:1.7.4-2 xserver-xorg-video-ati 1:6.12.4-2 xserver-xorg-video-mach64 6.8.2-2 xserver-xorg-video-r128 6.8.1-2 xserver-xorg-video-radeon 1:6.12.4-2 HTH Uli -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#506666: Can't reproduce here...
I tried the simple SDL_Init/SDL_Quit example from [1] and it doesn't crash. I also tried running tuxpaint, not crashing my machine either. The system is a current testing system, also on a Mac Mini G4. Attached is the xorg.conf file, notable differences are: - The whole "Module" section. - In the "Device" section the "MacModel" option, I'm not sure if this is important though. - In the "Device" section the "IgnoreEDID" option. My monitor actually reports more (60Hz) than it is really capable of (58Hz), so I have to program the timing manually. - I'm running at a display depth of 16 bit instead of 8. Actually, what depth are you running? I assumed it would use the first one, i.e. 8BPP in your case, is that true? However, I think this is mostly a mode for legacy code, as all others now use some kind of RGB encoding. I would definitely suggest trying 15/16/24 bits, too, that might already fix your problem. Uli [1] http://lazyfoo.net/SDL_tutorials/lesson01/linux/cli/index.php Section "Files" FontPath"/usr/share/fonts/X11/misc" FontPath"/usr/X11R6/lib/X11/fonts/misc" FontPath"/usr/share/fonts/X11/cyrillic" FontPath"/usr/X11R6/lib/X11/fonts/cyrillic" FontPath"/usr/share/fonts/X11/100dpi/:unscaled" FontPath"/usr/X11R6/lib/X11/fonts/100dpi/:unscaled" FontPath"/usr/share/fonts/X11/75dpi/:unscaled" FontPath"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/share/fonts/X11/Type1" FontPath"/usr/X11R6/lib/X11/fonts/Type1" FontPath"/usr/share/fonts/X11/100dpi" FontPath"/usr/X11R6/lib/X11/fonts/100dpi" FontPath"/usr/share/fonts/X11/75dpi" FontPath"/usr/X11R6/lib/X11/fonts/75dpi" # path to defoma fonts FontPath"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" EndSection Section "Module" Load"bitmap" Load"dbe" Load"ddc" Load"dri" Load"extmod" Load"glx" Load"int10" Load"vbe" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc104" Option "XkbLayout" "dvorak" Option "XkbVariant""dvorak" Option "XkbOptions""lv3:ralt_switch" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/input/mice" EndSection Section "Device" Identifier "Builtin Radeon" Driver "radeon" # select model with integrated DVI adapter Option "MacModel" "mini-internal" # ignore monitor mode lines received via DDC but use DDC to detect the monitor itself Option "IgnoreEDID" "true" Option "AccelMethod" "XAA" EndSection Section "Monitor" Identifier "SyncMaster 225BW on VGA" Option "DPMS" EndSection Section "Monitor" Identifier "SyncMaster 225BW on DVI" ModelName "SyncMaster" # 1680x1050 57.96 Hz (CVT) hsync: 63.06 kHz; pclk: 141.25 MHz Modeline "1680x1...@58" 141.25 1680 1784 1960 2240 1050 1053 1059 1088 -hsync +vsync Modeline "1680x1...@57" 140.25 1680 1784 1960 2240 1050 1053 1059 1088 -hsync +vsync Option "PreferredMode" "1680x1...@57" EndSection Section "Screen" Identifier "Default Screen" Device "Builtin Radeon" Monitor "SyncMaster 225BW on DVI" DefaultDepth16 SubSection "Display" Depth 1 Modes "1680x1050" "1280x1024" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 4 Modes "1680x1050" "1280x1024" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 8 Modes "1680x1050" "1280x1024" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 15 Modes "1680x1050" "1280x1024" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 16 Modes "1680x1050" "1280x1024" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 24 Modes "1680x1050" "1280x1024" "1024x768" "800x600" "640x480" EndSubSection EndSection Section "ServerLayout" Identifier "Default Layout" Screen "Def
Bug#560126: Similar problems here...
Mine aren't as severe, but at least they are enough to crash my X server, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561331. Further, also with a radeon card, I'm suffering a randomly corrupted cursor when moving between two windows ... I'll file a separate report unless already done by someone else. Uli -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#407680: pixel corruption (overflow in pixel operations, maybe Matrox driver?)
On Sunday 17 June 2007 02:48:56 Brice Goglin wrote: > About 5 years ago, you reported a bug to the Debian BTS regarding some > pixel corruption with Xorg and a matrox driver. Did you reproduce this > problem recently? With Xorg/Etch? With latest xserver-xorg-core 1.3 and > xserver-xorg-video-mga 1.4.6.1 currently in unstable? > If not, I will close this bug in the next weeks. If so, could you send > the output of > /usr/share/bug/xserver-xorg/script 3>&1 Hmmm, 5yrs is a pretty rough estimation. ;) Anyhow, I currently lack the hardware to reproduce the effect since the machine with the Matrox-card broke and I'm not going to rebuild it either. Uli -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407680: pixel corruption (overflow in pixel operations, maybe Matrox driver?)
Package: xserver-xorg Version: 7.1.0-10 When I drag a window or resize it, I get artifacts left over from that operation. Also, some 'normal' rendering operations are affected, I even see some weird light-effects in Quake 2. Now, those artifacts are not completely random. I used an Eterm in Enlightenment (I normally use fluxbox, I only used E because it displays position and size while moving/resizing) and positioned it at different positions and then used the resize-handle to create the rubber-band rect that shows the target-size. The results are X Yartifacts from 330 116 left side of rubberband 330 117 - 331 116 right side of rubberband 331 117 right side of rubberband 332 116 left side of rubberband ... I tried some more positions, the common factor seems to be that the X position is odd. Another similar effect occurs when moving a window. Just grab the window and wiggle it around a bit and you have the pixels all mixed up. You can still see the original content, so it is not a complete disaster, but nonetheless several pixels have weird colours. Speaking about colours, the effect is most visible on black and white. Also, the artifacts when moving a window typically occur to the right of dark/bright or bright/dark transitions, hence my guess that there is some kind of overflow or underflow in blitting operations. Note that these artifacts are removed when the area is redrawn, e.g. by moving another window over it. It isn't redrawn when just moving the mouse over it, even though I have the option "HWcursor" set to "off" in xorg.conf. Also, those artifacts are really there, i.e. not just something that is outside of X's control. What I mean is that when using Xmag, changing the resolution (with Ctrl-Alt-+/-) or scrolling the viewport those artifacts remain. This might give a hint where these operations take place that create the artifacts. Talking about Xmag, I took a closer look at the pixel values of those artifacts (I assume that when you click a pixel there that it displays the RGB values). I have a background with a single colour (white, RGB 0xff). Looking at the pixel-values of the artefact, I see following colours: fff9bf ffd9ff ffbfff fff8ff ffc8ff ffefff ffeeff ff7fff ff3fff ff37ff ffceff As you can see, typically the G channel is affected, resulting in magenta artifacts on the white background. This runs along the behaviour on black background, where the artifacts are typically green. Note that these artifacts only occur on every fourth vertical line of pixels. AFAICT (It's hard to measure this precisely) it occurs on the third, seventh, eleventh ... lines. Further, I'm also running a Matrox card. There are a handful of bugreports in the BTS that talk about Matrox cards and display problems. I'm not sure if those are related to what I am seeing, as they lack a precise description. In case that isn't clear, the artifacts don't have anything to do with window resizing/moving per se. I also see them right now while typing some text black on white. The point is just that e.g. the rubberband resizing makes this effect much more apparent. Uli -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: testers wanted for xfree86 4.1.0-14pre15v1
Setup: Athlon 1.4MHz Matrox G550 XServer XFree86 4.1.0-14pre15v3 using the drivers provided by Matrox (version 1.4.3) using single and dual-head layouts Status: working Good work,thanks! Uli -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: testers wanted for xfree86 4.1.0-14pre15v1
Setup: Athlon 1.4MHz Matrox G550 XServer XFree86 4.1.0-14pre15v3 using the drivers provided by Matrox (version 1.4.3) using single and dual-head layouts Status: working Good work,thanks! Uli -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
