New monitor, pink vertical line and crazy screen resolution with Evergreen + KMS

[Dave Witbrodt]

James Cloos wrote:
> I'd bet that if you were to tile something like this pbm (written
> directly info the mail buffer; I think I have the syntax correct):
> 
> P1
> 16 4
> 1010101010101010
> 0101010101010101
> 1010101010101010
> 0101010101010101
> 
> and were to look at it under magnification, you'd find that a couple of
> the columns were missing.  Ie, that the monitor had squeezed the 1920
> columns into 1918.

I can't check it right now.  I'll put it on my to-do list for the next 
time I have the HD 5750 installed.  I'm using the HD 4850 until some new 
support appears in radeon or the DRM.

Because the monitor itself is reporting a 1922 horizontal mode but only 
has 1920 physical pixels across, I would expect that the vertical line 
takes up 2 pixels per row, 1918 pixels follow those on each row, and 2 
more (to complete the 1920 mode being fed to the monitor by Linux) 
disappear off the end of each row.  This is pure speculation, of course.


> It probably can accept a range of resolutions -- just like analoge
> monitors of yore -- and scales them to fit its hw res.

It is certainly designed to do scaling, but I assumed that only specific 
scaled modes were allowed -- those listed in the monitor's manual.  I 
would have expected any mode involving more pixels (horizontally and/or 
vertically) than can be physically displayed to be rejected, most likely 
producing a black screen and possibly an on-screen display message from 
the monitor about an unsupported mode.  I believe I've seen some LCDs 
behave that way, though not recently, and never one that I owned.


> Even with KMS, I do still see a Printing probed modes for output
> section in my Xorg.0.log, but I see that the gtf(1) modelines do
> not match those, so comparing the ones from your monitor to gtf
> wouldn't be as illustrative as I had assumed.

Well, since the problem occurs in the DRM when KMS/radeondrmfb takes 
over from the BIOS VGA mode, I'm not sure that there's anything 
interesting for us to look at in Xorg.0.log.  My lovely pink line is 
there when I boot to a runlevel with X disabled; it goes away if I 
disable KMS, and rely solely on UMS/radeon modesetting.

The pink line is not caused by X.  It is caused by the HDMI connector 
support in DRM+KMS for Evergreen.


> Perhaps the pink or purple stripe is the (intended) sync pulse.
> 
> Maybe there is a bug in the atom bios which the driver needs to work
> around?

Sync pulse:  yes, like an error in the Evergreen (kernel) mode setting code.

AtomBIOS:  if a bug is present there, then ATI already has a solution -- 
Vista is able to handle both my DVI-to-HDMI converter cable and the 
regular HDMI cable without the pink line.  I am not knowledgeable about 
  hardware or driver software in general, but this tells me that the 
hardware (video card, monitor, and cables) are in good working order, 
and the problem must lie in the software support.  If AtomBIOS is 
problematic on my HD 5750, then ATI already knows how to work around the 
problem in their Windows drivers.

Since we have seen (on this mailing list) another user reporting the 
same vertical line on a different Evergreen card -- mine is HD 5750, his 
is HD 5870 -- then I think there is some simple programming error in the 
Evergreen KMS support.

My whole purpose in buying the card was to help the open source ATI 
driver developers with debugging.  I waited for several months before 
any indication of open source Evergreen support appeared.  The very 
first time Phoronix mentioned some Evergreen support was appearing, I 
immediately bought the fastest fanless Evergreen card available.  (I 
hate fan noise, and this card is totally silent! :)

I thought that since I had been spending a lot of time since November 
learning how to package upstream sources for my own Debian system, 
trying to get my (fanless) HD 4850 to work with 2D + 3D acceleration and 
KMS, I should put those newly-learned skills to work helping out with 
support for the next generation of hardware coming out.  I make my own 
DEBs, use 'git' to obtain new code from upstream, I modify code with 
patches, etc.  I hope to use these minimal skills to help with the 
Evergreen testing efforts.

I am not yet able to contribute code.  In fact, I've made no attempt to 
look at any radeon or DRM code, except for merging drm-radeon-testing 
into 2.6.33 when it was released (and fixing a few merge conflicts). 
Not being able hack the code (for lack of familiarity, and for lack of 
time to gain familiarity) is the most frustrating thing for me at the 
moment.  The fact that Evergreen support is currently featureless (and 
slightly broken on HDMI) doesn't bother me at all.  In fact, at this 
point I expected much more brokenness than this!  I just want to make 
myself available to help!

Any developers working on open source Evergreen support should feel free 
to ask me to test kernel patches, radeon patches, or (much later, no 
doubt) Mesa patches.  Anything I'm able to do, or that I'm able to 
_learn_ to do, I'll do.


Dave W.