Bug 30325

Summary:	[RADEON:KMS:RS780:MODESET] video=1280x720@50 no longer works
Product:	DRI	Reporter:	Marius Groeger <marius.groeger>
Component:	DRM/Radeon	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED MOVED	QA Contact:
Severity:	major
Priority:	medium
Version:	DRI git
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Marius Groeger 2010-09-22 02:21:17 UTC

With the current drm-radeon-testing my grub cmdline option video=1280x720@50 no longer works (RS780, output to LCD TV via HDMI). The fbcon apparently is enabled, but the TV doen't get a displayable picture anymore. Booting with d-r-t from 6 weeks ago works and correctly uses the EDID reported 1280x720@50 mode.

I did ask the same thing on the dri-devel mailing list and received no answer so I'm filing this bug both as another humble nudge to the authors of the drm video= code, and as a more persistent reminder of the issue.

Thanks
Marius

Comment 1 Alex Deucher 2010-09-24 10:29:36 UTC

Can you bisect what commit broke it?  I suspect it's something in the common drm code.

Comment 2 Marius Groeger 2010-09-27 10:13:16 UTC

(In reply to comment #1)
> Can you bisect what commit broke it?  I suspect it's something in the common
> drm code.

Well my point was to ask the people who where involved in recent changes to the drm code to thínk what commit might have broken this. The amount of commits is very large and I was hoping for help to shortcut. All I know is that it broke between d-r-t 2010-08-02 2046h and 2010-09-09 1910h.

I did check commit adde0f23396fe6c6cd4fe8e66e9cdc7d1f5081d9 but that doesn't seem to be the cause.

How do I determine a git base version if I only have a date/time?

Comment 3 Marius Groeger 2010-09-29 01:58:39 UTC

(In reply to comment #1)
> Can you bisect what commit broke it?  I suspect it's something in the common
> drm code.

There's FAR to many commits involved as during this interval the 2.6.35->2.6.36-rc merged happened. So I'm stuck. With the current d-r-t it seems even worse, I even don't get an X display anymore. (Haven't checked the logs though, yet).

For the second time (the last issue was a latency problem due to excessive drm locking.) I'm hitting a major drm regression and can't do anything about it. This is very disappointing. So, what can we do about it in the future?

As there are no regression tests, the testing is done by the community. Would it be possible to increase the frequency of updates to d-r-t? Or stay closer to the current linus tree?

Comment 4 Marius Groeger 2010-10-14 07:11:51 UTC

This is getting weirder and weirder. With the current d-r-t there are no 50Hz modes available anymore AT ALL!

Tried setting the TVStandard option - no change.

Started X without xorg.conf - no change.

Manually adding the 50Hz modes with xrandr works, but wasn't necessary in the past.

What logs would be interesting for further investigation?

Comment 5 Alex Deucher 2011-02-09 08:55:42 UTC

This was a apparently due to a drm core change:
https://bugzilla.kernel.org/show_bug.cgi?id=21542

Comment 6 Martin Peres 2019-11-19 08:15:42 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/159.

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.