Created attachment 33401 [details]
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.
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
1024x768 85.0 75.1 70.1 60.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.
Created attachment 33402 [details]
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?
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?
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:
Nice, just applied the patch and 1024x768@85Hz works again!