Bug 26639

Summary: [radeon KMS] switching to res 1024x768 kills output
Product: DRI Reporter: Tobias Jakobi <liquid.acid>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: jb.faq
Version: DRI git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg output
none
xorg logfile
none
EDID extracted from P260
none
xorg log when output works none

Description Tobias Jakobi 2010-02-18 13:12:19 UTC
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
Comment 1 Tobias Jakobi 2010-02-18 13:13:45 UTC
Created attachment 33402 [details]
xorg logfile
Comment 2 Tobias Jakobi 2010-02-18 13:24:00 UTC
Created attachment 33403 [details]
EDID extracted from P260
Comment 3 Alex Deucher 2010-02-18 22:57:12 UTC
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
Comment 4 Tobias Jakobi 2010-02-19 02:11:49 UTC
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?
Comment 5 Alex Deucher 2010-02-19 08:18:16 UTC
(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.
Comment 6 Tobias Jakobi 2010-02-19 14:49:58 UTC
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?
Comment 7 Alex Deucher 2010-02-19 15:20:14 UTC
(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?
Comment 8 Tobias Jakobi 2010-02-19 15:38:00 UTC
Created attachment 33441 [details]
xorg log when output works
Comment 9 Alex Deucher 2010-02-23 10:20:41 UTC
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
Comment 10 Tobias Jakobi 2010-02-23 13:10:45 UTC
Nope, makes no difference.

By UMS you mean userspace mode setting? Like I said this works - modprobe radeon with modeset=0 and switching works.
Comment 11 Alex Deucher 2010-02-23 19:14:08 UTC
Does the patch on bug 26668 help?
Comment 12 Tobias Jakobi 2010-02-24 14:42:34 UTC
No, just applied the fix to my tree but the issue stays the same.
Comment 13 Tobias Jakobi 2010-03-09 07:04:34 UTC
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
Comment 14 Alex Deucher 2010-03-09 07:11:22 UTC
(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).
Comment 15 Tobias Jakobi 2010-03-09 14:35:28 UTC
Yeah, you're right - it picks the 60Hz. Looks like I have to manually edit the INI to let it choose the 85Hz mode.
Comment 16 Tobias Jakobi 2010-04-15 15:47:54 UTC
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.
Comment 17 Alex Deucher 2010-05-13 14:18:07 UTC
This is a bug in the drm edid handling.  Patch is here:
http://lists.freedesktop.org/archives/dri-devel/2010-May/000611.html
Comment 18 Tobias Jakobi 2010-05-16 13:36:20 UTC
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.