Created attachment 33401 [details] dmesg output Hi there, switching to resolution 1024x768 doesn't work on my hardware (RV740 + IBM P260 CRT), the CRT simply fails to receive a signal and shuts down. xrandr output: Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192 DVI-0 disconnected (normal left inverted right x axis y axis) DIN disconnected (normal left inverted right x axis y axis) DVI-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 388mm x 291mm 1280x1024 85.0*+ 75.0 1600x1200 85.0 1024x768 85.0 75.1 70.1 60.0 960x529 75.0 800x600 85.1 72.2 75.0 60.3 56.2 640x480 85.0 72.8 75.0 60.0 720x400 87.8 70.1 1280x1024 is the standard mode and I just tried it: Every other mode works completly fine - just the 1024x768 mode results in no signal. No interesting output in dmesg when switching via xrandr. Kernel is uptodate drm-linux branch of airlied's tree. But this also happens with drm-radeon-testing. Not sure if it's a KMS problem, but at least it happens with KMS enabled. I can try a testrun with modeset disabled, if that helps. Greets, Tobias
Created attachment 33402 [details] xorg logfile
Created attachment 33403 [details] EDID extracted from P260
which 1024x768 mode is problematic? You have 4 of them: 1024x768 85.0 75.1 70.1 60.0 Does loading the radeon module with new_pll=0 help? e.g., modprobe radeon new_pll=0
Yeah, sorry about that. I was talking about the 85hz refresh rate one, I mostly use 85hz refresh when it's available. Going to test the new_pll parameters this evening and probably going to do also a check with KMS disabled. Would it help to check the 1024x768 mode with the other refresh rates?
(In reply to comment #4) > Would it help to check the 1024x768 mode with the other refresh rates? > for thoroughness, but if they do have problems, it's likely the same issue as the 85 hz one.
OK, tests done. First of all: All other 1024x768 modes except the 85Hz one work, it's just this single one that makes the signal go weird Disabling new_pll -> no change at all Disabling KMS does the trick, switching to 1024x768 works again Ready for more tests, so what should I do?
(In reply to comment #6) > OK, tests done. > > First of all: All other 1024x768 modes except the 85Hz one work, it's just this > single one that makes the signal go weird > > Disabling new_pll -> no change at all > Disabling KMS does the trick, switching to 1024x768 works again Can you attach the log from the working run?
Created attachment 33441 [details] xorg log when output works
Does UMS from git master, or this patch for KMS help? http://people.freedesktop.org/~agd5f/0001-drm-radeon-kms-update-new-pll-algo.patch
Nope, makes no difference. By UMS you mean userspace mode setting? Like I said this works - modprobe radeon with modeset=0 and switching works.
Does the patch on bug 26668 help?
No, just applied the fix to my tree but the issue stays the same.
A funny (maybe significant?) detail: ut2003 works in 1024x768 mode - my guess is that it's not using xrandr to switch the res but the old method, I think it was via XVidMode
(In reply to comment #13) > A funny (maybe significant?) detail: > ut2003 works in 1024x768 mode - my guess is that it's not using xrandr to > switch the res but the old method, I think it was via XVidMode > It's likely not picking the same mode (i.e., probably not the same 85 hz mode).
Yeah, you're right - it picks the 60Hz. Looks like I have to manually edit the INI to let it choose the 85Hz mode.
Yesterday I updated libdrm, mesa and xf86-video-ati to git master tip and also pulled the latest stuff from drm-radeon-testing. Issue is still there.
This is a bug in the drm edid handling. Patch is here: http://lists.freedesktop.org/archives/dri-devel/2010-May/000611.html
Nice, just applied the patch and 1024x768@85Hz works again!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.