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.
_______________________________________________
xorg-driver-ati mailing list
[email protected]
http://lists.x.org/mailman/listinfo/xorg-driver-ati
