Created attachment 34610 [details]
BootDmesg.txt

Created attachment 34611 [details]
CurrentDmesg.txt

Created attachment 34612 [details]
XorgLog.txt

Created attachment 34613 [details]
XorgLogOld.txt

Created attachment 34614 [details]
Xrandr.txt

How was it determined that 'the color depth changes from 24 bit to 8 bit'? The X server can't change depth at runtime.

If it's that the colours become dark or otherwise broken, it could be a duplicate of bug 27382.

I'm not sure how he's determining that.  His xdpyinfo looks completely normal:  http://launchpadlibrarian.net/41230371/xdpyinfo.txt

Perhaps he means to say that the screen appears to lose color depth.  Maybe we need a photo.

Here's the user's reply.  Photos and some regdump data in the link below.

Hello Bryce,

I thank you for your questions.

I have no reliable information on the real color depth after
suspend/resume. I have just assumed that it could be something similar.
Therefore I attached two photos on the screen after such actions. (Sorry
my cam is horrible so you will be able to see rather distorted images
but the phenomena looks clear.)

I've also checked the PID of Xorg

$ ps -A |grep Xorg
  964 tty7     00:00:13 Xorg

therefore I copied some files from /proc/964 to the compressed directory
attached here. There is a subdir within named as 964.

I also performed the actions you requested with radeontool. There is a
regdump_broke_local.txt and regdump_broke_remote.txt along with the
regdump_good.txt file. regdump_broke_local.txt is the gathered info
using the broken screen. regdump_broke_remote.txt is the same but I
logged in remotely.

I hope this helps! Thanks, Zoltan


** Attachment added: "radeontool regdumps + photos"
   http://launchpadlibrarian.net/42921659/bug_rep.tgz

Please, send me your questions in connection with this bug in the future.
Regards,
Zoltan

If you want a bug tracked here, attach all the information here directly.

Does running something like

xgamma -gamma 1.0

fix the problem?

Any news here? I seem to suffer the same problem?!

When using reboot from main-menu, the screen darkens and the question "restart" appears. After boot, there is a shading that looks nice ... after resume the shading are real circles, which leads me to the opinion, that the color-depth is different ... which could also be seen in plymouth, where there are stripes now

This bug is not specific for x86-64. I'm having 32 bit Bliss 507s laptop (non-major brand, made from ARIMA components /ARIMA M621-DC alike/) with 1st generation Centrino and Pentium M with ATI x700 as well. After looking at attached photos I confirm that I have similar behavior. These noisy non-steady colored dots don't appear on a screenshot. I'm not sure if screenshot program took snapshot from video memory or not (what screen dumper to use?).

(In reply to comment #12)
> These noisy non-steady
> colored dots don't appear on a screenshot...

Does the image corruption go away after resetting output gamma? (using xgamma or xrandr's --gamma option)

mlt@mlt-laptop:~$ xgamma -gamma 1.0
-> Red  1.000, Green  1.000, Blue  1.000
<- Red  1.000, Green  1.000, Blue  1.000

I can't figure out options format for xrandr as
xrandr --gamma 1:1:1
prints usage instructions

mlt@mlt-laptop:~$ cat /proc/version
Linux version 2.6.38-10-generic (buildd@roseapple) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) ) #44-Ubuntu SMP Thu Jun 2 21:32:54 UTC 2011

I'm not sure if OP on launchpad correctly described the problem. These noisy dots happen only in some areas of the screen. Some of the dots are jittery/non-steady. Also if I move mouse over impaired area, cursor looks okay. First time I thought it may be overheating of my video card or bad memory, but after a clean reboot everything works just fine.

(In reply to comment #14)
> mlt@mlt-laptop:~$ xgamma -gamma 1.0
> -> Red  1.000, Green  1.000, Blue  1.000
> <- Red  1.000, Green  1.000, Blue  1.000

I forgot to mention that it doesn't help.

Another issue I noticed that screen jitters a lot while dragging let's say scroll bar in firefox on this bug report web page. It doesn't happen on clean boot (client only area is smoothly scrolled in this case), only after resume.

I'm not sure if there might be problem with timing. How do I check that? I don't know much about LCD panel, if it needs also a proper initialization.

Perhaps it would be helpful, if I shoot a video.

You can try dumping the display registers in the working and non-working cases using radeonreg which is available here:
http://cgit.freedesktop.org/~airlied/radeontool/

As root:
./radeonreg regs radeon > working.dump

./radeonreg regs radeon > broken.dump

And attach the dumps here.

Created attachment 49099 [details]
sudo ./radeontool regs > working.dump

Created attachment 49101 [details]
sudo ./radeontool regs > broken.dump

Created attachment 49104 [details] [review]
difference between working and broken dumps

Here is the video http://vimeo.com/26459546 . I lost sound for some reason when I was converting the video with ffmpeg for vimeo.

I was wrong about screen jittering while scrolling after resume. It does happen even before suspend at lesser extent, however disappears if I remove all PM related options.

However original issue is still there with no extra options enabled that caused that screen jittering:
 - at boot time radeon.dynclks=1 radeon.agpmode=4
 - in /etc/X11/xorg.conf : Option      "AccelMethod" "EXA"
 - echo "dynpm" > /sys/class/drm/card0/device/power_method

I still need to double check what causes that "jittering", but it is a separate issue.

(In reply to comment #15)
> (In reply to comment #14)
> > mlt@mlt-laptop:~$ xgamma -gamma 1.0
> > -> Red  1.000, Green  1.000, Blue  1.000
> > <- Red  1.000, Green  1.000, Blue  1.000
> 
> I forgot to mention that it doesn't help.

I tried values for gamma other than 1. It does change artifacts pattern on screen. For -gamma 0.1, visible amount of artifacts diminishes and only substantially brights areas are affected. For -gamma 1.2, nonuniform blueish artifacts start to show up on dark areas. For -gamma close to 10, only greenish artifacts are visible on bright areas and I barely see any blueish noise.

If I try to switch to console with Ctrl+Alt+F1, I can see somewhat uniform pinkish high frequency non-steady noise instead of blackness of the console. Also there is a somewhat darker red vertical strip 1/3 from the left edge. I'm using default Ubuntu settings so video mode doesn't change at least visibly when I switch to console and back.
http://imagebin.org/163211

Created attachment 49120 [details]
./radeonreg regs radeon > working.dump

I apologize, I uploaded wrong dump before.

Created attachment 49121 [details]
./radeonreg regs radeon > broken.dump

Created attachment 49122 [details]
difference between working and broken dumps

I'm not sure if pushing some register values from working state was the right thing to try.

awk 'BEGIN{ORS="|"};{if($1=="<" && $4!="")print "0x" $2, "0x" $3}' wb.diff | xargs -d "|" -L 1 echo ./radeonreg regset > cmds.sh
sh cmds.sh

This did a minor temporal damage in upper part of the screen for working conditions. However when I tried to execute it after resume, it made screen flashy then it faded out and essentially froze the system.

I'm not sure what are those byte long registers as radeonreg regmatch doesn't know them.

I've noticed that when KMS is disabled I don't have that issue after resume. Though radeon appears in lsmod, I don't have hardware OpenGL rendering as I get something like the following in log file:

AIGLX: Trying DRI driver /usr/lib/dri/r300_dri.so
AIGLX error: Calling driver entry point failed
AIGLX: reverting to software rendering

As far as I understand I can't get hardware rendering without KMS anymore.

I was not careful enough, it happens in xorg 7.6 that I have with Ubuntu 11.04, it is not specific to 7.4. I'm not sure if it makes sense to correct this bug description (version,platform, and description itself as it is not a color depth degradation).

Created attachment 49227 [details]
Another ./radeonreg regs radeon > broken2.dump

I noticed that this dump is different from previous one.

Strange, looks like the neither plls nor the palette regs aren't programmed after resume.  Does forcing a mode set after resume help?  E.g.,

xrandr --output LVDS --mode 800x600
xrandr --output LVDS --auto

If not, do the following commands help?

sudo ./radeonreg regset 0x00000284 0x1bd34008
sudo ./radeonreg regset 0x000002d0 0x003c00a5

If that alone doesn't fix it, in addition, try:

sudo ./radeonreg regset CL:03 0x001c0007
sudo ./radeonreg regset CL:04 0x00010038
sudo ./radeonreg regset CL:05 0x00010038
sudo ./radeonreg regset CL:06 0x00010038

Yeay! The last suggestion did the magic!

mlt@mlt-laptop:~/workspace/radeontool$ xrandr --output LVDS --mode 800x600
mlt@mlt-laptop:~/workspace/radeontool$ xrandr --output LVDS --auto
mlt@mlt-laptop:~/workspace/radeontool$ sudo ./radeonreg regset 0x00000284 0x1bd34008
OLD: 0x00000284 (0284)	0x00004008 (16392)
NEW: 0x00000284 (0284)	0x1bd34008 (466829320)
mlt@mlt-laptop:~/workspace/radeontool$ sudo ./radeonreg regset 0x000002d0 0x003c00a5
OLD: 0x000002d0 (02d0)	0x003c0085 (3932293)
NEW: 0x000002d0 (02d0)	0x003c00a5 (3932325)

So far no improvements, but the following fixed it

mlt@mlt-laptop:~/workspace/radeontool$ cat -> cmds.sh
sudo ./radeonreg regset CL:03 0x001c0007
sudo ./radeonreg regset CL:04 0x00010038
sudo ./radeonreg regset CL:05 0x00010038
sudo ./radeonreg regset CL:06 0x00010038
mlt@mlt-laptop:~/workspace/radeontool$ sh cmds.sh 
OLD: CL:03 (CL: 0003)	0x001c003f (1835071)
NEW: CL:03 (CL: 0003)	0x001c0007 (1835015)
OLD: CL:04 (CL: 0004)	0x000001bb (443)
NEW: CL:04 (CL: 0004)	0x00010038 (65592)
OLD: CL:05 (CL: 0005)	0x000001f2 (498)
NEW: CL:05 (CL: 0005)	0x00010038 (65592)
OLD: CL:06 (CL: 0006)	0x000001bb (443)
NEW: CL:06 (CL: 0006)	0x00010038 (65592)
mlt@mlt-laptop:~/workspace/radeontool$ 

When I tried to execute it line by line, I got flashy "burned" looking screen that faded after the first line, and system became frozen.

(In reply to comment #30)
> If that alone doesn't fix it, in addition, try:
> 
> sudo ./radeonreg regset CL:03 0x001c0007
> sudo ./radeonreg regset CL:04 0x00010038
> sudo ./radeonreg regset CL:05 0x00010038
> sudo ./radeonreg regset CL:06 0x00010038

Created attachment 49250 [details]
This is what I got after warm restart. (Restart through Ubuntu menu)

I'm not sure if problem from attaches screenshot is related, if something is not initialized properly. Though I mentioned that clean boots are usually fine. Very very rare I get this.


The following workaround can be used for now in Ubuntu 11.04 . radeonreg should be placed in /usr/local/bin/

mlt@mlt-laptop:~$ cat /etc/pm/sleep.d/20_radeon 
#!/bin/sh

# Workaround for radeon resume

PATH=/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin

case "${1}" in
        resume|thaw)
		echo "Doing my things" > /tmp/radeon.log
		radeonreg regset CL:03 0x001c0007 >> /tmp/radeon.log 2>&1
		radeonreg regset CL:04 0x00010038 >> /tmp/radeon.log 2>&1
		radeonreg regset CL:05 0x00010038 >> /tmp/radeon.log 2>&1
		radeonreg regset CL:06 0x00010038 >> /tmp/radeon.log 2>&1
		echo "Done" >> /tmp/radeon.log
                ;;
esac

Can you enable kms debugging (as root):

sudo bash -c "echo 0x4 > /sys/module/drm/parameters/debug"

then suspend and resume and attach the resulting dmesg output?

Created attachment 49283 [details]
dmesg output after resume, no previously described workaround has been applied

(In reply to comment #33)
> Can you enable kms debugging (as root):
> 
> sudo bash -c "echo 0x4 > /sys/module/drm/parameters/debug"
> 
> then suspend and resume and attach the resulting dmesg output?

Created attachment 49284 [details]
Clean dmesg from boot up as previous attachment contains data from previous resumes

(In reply to comment #34)
> Created an attachment (id=49283) [details]
> dmesg output after resume, no previously described workaround has been applied

(In reply to comment #31)
> Yeay! The last suggestion did the magic!
...
> mlt@mlt-laptop:~/workspace/radeontool$ sudo ./radeonreg regset 0x000002d0
> 0x003c00a5
> OLD: 0x000002d0 (02d0)    0x003c0085 (3932293)
> NEW: 0x000002d0 (02d0)    0x003c00a5 (3932325)
> 
> So far no improvements, but the following fixed it

I was wrong. This command is also necessary after all I confirmed before otherwise there is a noticeable stairs effect, after this command gradients looks smoother.

Original reporter hasn't responded to information request in 2 years.