| Summary: | Evergreen KMS DRM sets bizarre 1922x1200 resolution | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Dave Witbrodt <dawitbro> |
| Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | mail, sokann |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
|
Description
Dave Witbrodt
2010-04-04 13:57:22 UTC
Seeing the recent set of commits touch on Evergreen support, I tested a new kernel using "drm-radeon-testing" up to commit 98e5963 of Apr. 9, 2010. I'm not interested in UMS, so I configured to default to KMS. My monitor only has VGA and HDMI inputs, and I'm only interested in seeing the problem with HDMI support for Evergreen solved in this bug report, so I only tested with the HDMI cable.
Results:
- still have pink line along left side of screen (2 pixels wide)
- monitor OSD still reports crazy 1922x1200 mode (instead of 1920x1200)
- it is known that the hardware (both video card and monitor) are fine: Windows uses HDMI-to-HDMI cable (and DVI-to-HDMI cable) without problems
- as before, X runs fine; I will include Xorg.0.log for completion (problem is in KMS/radeondrmfb, not X, though) in case any helpful info is present there
Brainstorming:
- looked at some of the DRM code, but couldn't understand HDMI connection
code; apparently something in the ATOMBIOS functionality between HD 4XXX
and HD 5XXX is subtly different
- possibly the problem arises with the KMS equivalent of what would be called modelines in X: the Xorg.0.log shows that the preferred mode for the monitor (1920x1200) is set using detailed timings reported by the monitor; this is fine with UMS (and KMS on HD 4850), but fails with KMS on HD 5750 ...
(II) RADEON(0): Supported detailed timing:
(II) RADEON(0): clock: 154.0 MHz Image Size: 593 x 371 mm
(II) RADEON(0): h_active: 1920 h_sync: 1968 h_sync_end 2000
h_blank_end 2080 h_border: 0
(II) RADEON(0): v_active: 1200 v_sync: 1203 v_sync_end 1209
v_blanking: 1235 v_border: 0
[FYI: the "drm-radeon-testing" commits now require JUNIPER*.bin firmware blobs, but I did download them and add them to my kernel with a built-in initramfs -- see attached 'dmesg' output.]
Created attachment 34874 [details]
dmesg from drm-radeon-testing kernel 2.6.34-rc3 (Apr. 9, 2010)
Created attachment 34875 [details]
Xorg.0.log from drm-radeon-testing kernel 2.6.34-rc3 (Apr. 9, 2010)
Created attachment 34876 [details]
Output from 'hwinfo' and 'fbset'
Out of curiosity, I thought I would run 'hwinfo' and 'fbset' to see what they reported about radeondrmfb. This output is probably useless, but I'm attaching it just in case....
Running 'hwinfo --framebuffer' does not even report 1920x1200 as a possible mode, and 'hwinfo --monitor' reports nothing at all.
I have that same problem. Radeon 5750 connected to a projector via HDMI, resolution is set to 1920x1080, projector reports 1922x1080, pink line on the left from top to bottom running debian sid with xserver-xorg-video-radeon 1:6.13.0-1 and a custom compiled (vanilla) linux 2.6.34-rc3 kernel Created attachment 35137 [details]
dmesg from 2.6.34-rc4 (+ recent drm-radeon-testing) with drm.debug=7
Built a new kernel with 2.6.34-rc4 on the night it was released. Also saw some new commits in drm-radeon-testing, so merged them with it (up to commit 3a44d81 of Apr. 10).
Had my HD 4850 installed then and since, but today finally found time to swap in the HD 5750 and try it out. Also (accidentally) discovered the "drm.debug" kernel parameter, so I tested the new kernel by booting to a non-X runlevel with drm.debug=7 enabled.
Results from 'dmesg' attached. Still get the pink vertical line on the left side of screen; monitor's OSD still reports crazy 1922x1200 resolution instead of 1920x1200.
Created attachment 35158 [details]
/sys/class/drm/card0-HDMI Type A-1/edid
added some debug statements to atombios_crtc_mode_set to print out the contents of the mode and adjusted_mode structures (which were identical):
crtc_hsync_start: 2008
crtc_hsync_end: 2052
crtc_hdisplay: 1920
crtc_hblank_end: 2200
crtc_vsync_start: 1084
crtc_vsync_end: 1089
crtc_vdisplay: 1080
crtc_vblank_end: 1125
flags: 5
bug still there with 2.6.34-rc5 + drm-radeon-testing 10fd883ce384706f88554a0b08cc4d63345e7d8b Created attachment 37676 [details]
dmesg from 2.6.35 with drm.debug=15
I have still been testing kernels to see if this bug goes away, but there has been no change since last time I posted to this bug. Today, I tested the HD 5750 card with 2 kernels:
- A much older kernel, which I had forgotten to test with the 5750:
linux 2.6.34 + drm-radeon-testing (up to commit 0818fe9 of 04/29/2010)
- linux 2.6.35 (built on 08/01/2010)
Both kernels still result in a pinkish/purplish vertical line along the entire left side of the screen when using the HDMI cable.
Using a HD 4850 card with both kernels (and HDMI) works fine.
Looking carefully, I am noticing that (with the 5750) there is also a black gap at the top and on the left -- maybe 2 or 3 mm wide. The bug also has always caused the monitor's onscreen display to report 1922x1200 resolution (the 1922 should be 1920, of course); this doesn't happen with the 4850 card.
I believe also that the pink vertical line (a few pixels wide) may be before the addressable pixels of the screen. That is, I'm not sure that I'm losing actual screen space to the pink line, but that the image that ought to be displayed is actually just shifted to the right (and down) from where it ought to be. Seems like the sort of timing problem one might have seen in the old days on a CRT.
Attached is dmesg from 2.6.35 with "drm.debug=15" boot parameter.
(In reply to comment #10) [...] > Looking carefully, I am noticing that (with the 5750) there is also a black gap > at the top and on the left -- maybe 2 or 3 mm wide. Umm, strike this, please. Because of the pink line issue, I don't leave the 5750 installed -- I remove it after testing and use the 4850 instead. I see that the gaps (which I hadn't noticed before) are actually normal. The X server, for some reason, detects DPI differently when I swap cards, so what looked to me like screen real estate being cut off at the bottom of the screen was probably an artifact of the fonts being a different size when the 5750 was installed. Fixed with this patch: http://lists.freedesktop.org/archives/dri-devel/2010-August/003142.html (In reply to comment #12) > Fixed with this patch: > http://lists.freedesktop.org/archives/dri-devel/2010-August/003142.html Applied patch. Installed HD 5750 card. Verified that pink vertical line is gone. Thanks Alex! (In reply to comment #12) > Fixed with this patch: > http://lists.freedesktop.org/archives/dri-devel/2010-August/003142.html Any news on the real cause of the problem? Completely unrelated but we have an HDMI driver for another platform here (ARM-based with an SII9022 HDMI transmitter) and when operating in HDMI mode to get audio (before we've even configured audio...) we're getting this very same pink line down the side of the screen. We've got no idea where it came from or what might cause it.. some quirk in CEA mode timings? HDMI being less tolerant of a slightly askew pixel clock? Who knows, but I would love to see someone tell me what causes this stuff. It's obviously the horizontal back porch showing through but we're pulling EDID data from the monitor and converting it directly (and very accurately) to framebuffer timings.. (In reply to comment #14) > (In reply to comment #12) > > Fixed with this patch: > > http://lists.freedesktop.org/archives/dri-devel/2010-August/003142.html > > Any news on the real cause of the problem? When running in HDMI mode, the monitor expects properly formatted CEA infoframe packets (for audio, 3D, colorspace, etc.) from the source, however, at the moment, we don't yet have support for them in the open source driver for evergreen hw. The monitor can misinterpret the bogus/missing infoframe packets and do strange things. |
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.