Anders Eriksson wrote:

mhopf@suse.de said:

...

Given that the log shows that 1920x1080 is detected, but xrandr doesn't, this is clearly an RandR issue. I don't understand why the higher resolution is nuked.

...

In the HDMI only case, the resolution is set to - hold your grip - 720x400... No wonder your monitor isn't capable of displaying anything...

...

Ah. I found something. (II) RADEONHD(0): clock: 148.5 MHz Image Size: 160 x 90 mm

I tried fiddling with the Monitor section and it turns out that if i 1 diable randr, 2 set the display size 3 set the DPI 4 forcereduced

I can get 1920x1080 on HDMI with ok font size (the DPI did that)!! However, there are some static horizontal lines on the display whenever I show anything but the KDE background.

It seems that under randr the Monitor section is not honored at all. Thought the Option "Monitor-DVI-D_1" "Monitor1" line should fix that. Am I missing something?

Here is my xorg... the location of the Option "Monitor-DIV-D_1" "Monitor1" stuff got me confused at first... This is for a dual screen setup, but there rest should be pretty self explanatory. Section "Monitor" Identifier "monitor1" Option "monitor-DVI-0" "monitor1" Option "RightOf" "monitor2" EndSection Section "Monitor" Identifier "monitor2" Option "monitor-DVI-1" "monitor2" EndSection Section "Device" Identifier "X1650Pro" Option "monitor-DVI-0" "monitor1" Option "monitor-DVI-1" "monitor2" Option "RROutputOrder" "monitor1" EndSection Section "Screen" Identifier "MyScreen" Device "X1650Pro" SubSection "Display" Virtual 3840 1200 EndSubSection EndSection -- Nathanael d. Noblet Gnat Solutions, Inc T: 403.875.4613 -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

mhopf@suse.de said:

With randr try to nuke the 'Monitor "Monitor1"' from the Screen section. So the only references are the 'Option "Monitor-XYZ"' in the Device section.

Tried that: * Both the HDMI and VGA displays. * VGA 1920x1080 everthing ok * HDMI gets a desktop size which is larger than the screen. On all edges, about 2 cm of the desktop is carwed off (the left column of icons and the bottom panel in KDE). Additionally, th statics is there _but_ not as intense. xrandr and xdpyinfo both attests that both outputs are 1920x1080. It doesn't scroll as the classic "virtual large desktop" X thing. The text looks stretched and the scroll list in Kterm shows a repeating wavy stretch pattern. mhopf@suse.de said:

...

However, there are some static horizontal lines on the display whenever I show anything but the KDE background. Sounds like a completely different problem. Try Option "AccelMethod" "shadowfb" as a start. If that works, you're hitting an acceleration bug.

No improvement. Tried "shadowfb", "exa", "none", removing the line. With randr (i.e. as above) I get less static. Maybe one horizontal line "blip" every 2 seconds. Without randr (i.e. with all of the desktop shown on the monitor), I get 4-7 lines jumping around more or less all the time. My imression is that I get more lines when I place some windows on the otherwise homogeneous blue background. I can send you a small video of the phenomenon if you want to. /Anders -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

mhopf@suse.de said:

On Feb 05, 09 20:33:18 +0100, Anders Eriksson wrote:

...

Tried that: * Both the HDMI and VGA displays. * VGA 1920x1080 everthing ok * HDMI gets a desktop size which is larger than the screen. On all edges, about 2 cm of the desktop is carwed off (the left column of icons and the bottom panel in KDE). Additionally, th statics is there _but_ not as intense.

xrandr and xdpyinfo both attests that both outputs are 1920x1080. It doesn't scroll as the classic "virtual large desktop" X thing. The text looks stretched and the scroll list in Kterm shows a repeating wavy stretch pattern.

Sounds very much like overscan. Many TVs don't display HD in a 1:1 fashion. Which is IMHO broken, but hell...

After having added the UseAtome BIOS option I still see this phenomenon.

...

mhopf@suse.de said: No improvement. Tried "shadowfb", "exa", "none", removing the line. With randr (i.e. as above) I get less static. Maybe one horizontal line "blip" every 2 seconds. Without randr (i.e. with all of the desktop shown on the monitor), I get 4-7 lines jumping around more or less all the time. My

...

Ok, sounds different. Please try Option "UseAtomBIOS" "true" and report back.

That did the trick for the statics in the image! However, the display size is still too large. (About 2 cm chopped off on all 4 edges). /Anders -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Matthias Hopf writes:

On Mar 09, 09 15:52:12 +0100, Anders Eriksson wrote:

...

...

...

Ok, sounds different. Please try Option "UseAtomBIOS" "true" and report back.

That did the trick for the statics in the image!

Ok, another issue with electrical values. Have to think whether to make AtomBIOS modesetting the default.

I'm sorry for jumping in the thread, but i can't resist. I thought that proper modesetting was one of the main goals for radeonhd from the beginning. And now, just after Luc left, you say that it's possible you'll make AtomBIOS blobs (essentially, i know that AMD calls it scripts, but it doesn't mean anything unless you have an easy way to change them) the default, which will considerably lower the amount of testing for proper modesetting and therefore will defeat one of the primary goals. Am i understanding it right? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@gmail.com -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Matthias Hopf writes:

The most important goal of radeonhd was to create a new, well-designed and maintainable code base. Sometimes you have to start over to get rid of old blobs, especially in drivers when the programming model changes fundamentally. Which it did, modesetting wise with R5xx, 3D-wise with R6xx. The line we draw was reasonable because modesetting comes first, acceleration later.

And btw i forgot to say "thank you" to all the radeonhd team for all the efforts and work you're doing to produce a truly open well-designed driver for modern cards. You guys rock!

Luc also has had a hard time with BIOS related issues in the past, so [snip] Turns out that the issues weren't as severe as we thought.

But that's just a happy coincidence, if i understand it right. Sooner or later it will break, because it's defective-by-design.

Also, AMD is apparently understaffed for preparing open documentation -

Hm, i was under impression that devs from Novell can get any documentation under NDA, was it changed since then? Is AMD not "open" enough to give some trusted devs any information they need even under NDA? If yes, then what's the reason behind that?

But now if Luc won't continue his work here we have to *think* about whether it would be wise to switch to AtomBIOS mode setting. I'm not saying that we should do it. This is something for discussion.

That makes me sad...

BTW - you broke the reply-to header... don't know whether your mail actually went to radeonhd or not.

There was no reply-to header, just gmane does one special trick to hide the real e-mail addresses. Still it works as it should, and my mail did reach the mailing list. Thanks for the clarifications... -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@gmail.com -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Matthias Hopf writes:

On Mar 09, 09 20:15:30 +0300, Paul Fertser wrote:

...

...

Luc also has had a hard time with BIOS related issues in the past, so [snip] Turns out that the issues weren't as severe as we thought.

But that's just a happy coincidence, if i understand it right. Sooner or later it will break, because it's defective-by-design.

AFAICS it's not defective by design, but rather defective by too little validation. Of course you could assume that this won't get better, as BIOS programmers tend to behave this way.

Even if they didn't, updating a driver is much easier than updating a videocard BIOS. And if ATI/AMD wanted "scripts", they should have probably done exactly what they claim they did: scripts. Imagine a free tool to byte-compile (probably through a c compiler directly to native shared object) well-commented scripts and that byte-compiled code loaded in the driver at runtime. And an easy way to override the scripts used. _That_ would be a reasonable compromise. I can't see how you can call the current AtomBIOS way to do things not defective comparing to that.

...

...

Also, AMD is apparently understaffed for preparing open documentation -

Hm, i was under impression that devs from Novell can get any documentation under NDA, was it changed since then? Is AMD not "open"

No, but we only get sanitized docs, maybe a little bit more verbose, and AMD isn't as sure about IP in the docs we get than in the public docs, but they don't want to taint us (and we don't want to get tainted), so it's still nontrivial.

Not sure what Imaginary Property you are talking about. As far as i understand there's no clear meaning in "IP" as it tends to be used everywhere for all kinds of completely different law tricks. Sometimes they talk about copyright and call it IP, sometimes they talk about usual ("hardware") patents and call it IP. Are you talking about software patents here? Does Novell really need to care about it as they're unenforceable in every sane jurisdiction? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@gmail.com -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On Mon, Mar 09, 2009 at 09:04:44PM +0300, Paul Fertser wrote:

Matthias Hopf writes:

...

On Mar 09, 09 20:15:30 +0300, Paul Fertser wrote:

...

...

Luc also has had a hard time with BIOS related issues in the past, so [snip] Turns out that the issues weren't as severe as we thought.

But that's just a happy coincidence, if i understand it right. Sooner or later it will break, because it's defective-by-design.

AFAICS it's not defective by design, but rather defective by too little validation. Of course you could assume that this won't get better, as BIOS programmers tend to behave this way.

Even if they didn't, updating a driver is much easier than updating a videocard BIOS.

And if ATI/AMD wanted "scripts", they should have probably done exactly what they claim they did: scripts. Imagine a free tool to byte-compile (probably through a c compiler directly to native shared object) well-commented scripts and that byte-compiled code loaded in the driver at runtime. And an easy way to override the scripts used. _That_ would be a reasonable compromise. I can't see how you can call the current AtomBIOS way to do things not defective comparing to that.

ATI does want to force you to use the BIOS bytecode they provided, but ATI, at all cost, refuses to provide people with updated bioses, even when there are known defects, as their official stance is close to "but it is perfect when we're done anyway". Everyone sane knows that a BIOS is just hardtoget-to/alter software, and that software is never perfect, so this is close to... hrm... bending the truth :) A while back a user here got an updated bios from his hw vendor, together with a tool to flash his bios. This made ati quite unhappy :) Now... What would be rather easy to do is code up something that loads a bios image provided as an option in your xorg.conf device section. This way you can load whatever image you want (at your own very explicit risk). Then we could look into cutting down the bios image to only hold the atombios part. Then we could look into assimilating our own images from something like atomdis output. The first step there is trivial, the second shouldn't be too hard either. The rest is for someone with a lot of time and clue. Personally i think it would be fun to spend a few minutes doing the first two bits, but i can't be bothered with the last bit. Luc Verhaegen. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On Mar 09, 09 17:48:01 +0100, Anders Eriksson wrote:

While on the subject of modesetting, how does all of this play with the recent KMS activities by the kernel guys? What's the plan for radeonhd and KMS?

Has not really been discussed yet. There is no principal issue with that, but we don't see the benefit at the current state of KMS (with changing interfaces etc.). Matthias -- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

mhopf@suse.de said:

...

However, the display size is still too large. (About 2 cm chopped off on all 4 edges).

You can only change that in the configuration of your TV - if at all.

Success! The TV did offer a way to adjust the screen size. Thanks a lot! /Anders -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org