Mailinglist Archive: radeonhd (312 mails)
| < Previous | Next > |
Re: [radeonhd] useconfiguredmonitor for CONNECTOR_PANEL
- From: Egbert Eich <eich@xxxxxxx>
- Date: Fri, 1 Feb 2008 20:53:36 +0100
- Message-id: <18339.30912.899193.50588@xxxxxxxxxxxxxx>
Thomas Meyer writes:
OK, you are using EFI mode, so there either isn't an AtomBIOS at all
or it is not available thru the 'PC-style' access methods.
We should find out if and how to find AtomBIOS on MacBooks booted
thru EFI.
OK
In your case, yes.
Yes, without AtomBIOS we don't know, what sort of panel is connected.
This is simply not supported (yet).
It would be possible to add this:
There are two possibilities:
1. You specify the size of the panel (and optionally a frequency).
We would use gtf to calculate a mode (with reduced blanking).
2. You specify the entire mode. This way you could also support
odd panels. I'm not sure if there are any use cases for this
and if so if we can expect from the user to obtain the information
needed.
ATM I'd opt for 1. from there we should look how far we get.
Independently we should investigate if it is possible to obtain
an AtomBIOS on an EFI booted macbook.
Cheers,
Egbert.
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx
That's because there is no AtomBIOS available! (and i did compile the
I wonder why your AtomBIOS doesn't contain anty panel information.
driver with disable-atombios and disable-atombios-parser).
OK, you are using EFI mode, so there either isn't an AtomBIOS at all
or it is not available thru the 'PC-style' access methods.
We should find out if and how to find AtomBIOS on MacBooks booted
thru EFI.
See also bug https://bugs.freedesktop.org/show_bug.cgi?id=13473 and
attached log.
OK
Summary:
"
(--) RADEONHD(0): Detected an M56 on a Macbook Pro
(II) RADEONHD(0): Mapped IO at 0xb7aac000 (size 0x00010000)
(II) RADEONHD(0): Getting BIOS copy from legacy VBIOS location
(EE) RADEONHD(0): Invalid BIOS length field
(II) RADEONHD(0): Query for AtomBIOS Init: failed
(--) RADEONHD(0): VideoRAM: 131072 kByte
"
Could you please provide us with a log file of your server?See above.
Maybe you could also send a copy of your BIOS to libv or me.I think this is not useful, see above.
You can use rhd_conntest <pci_id> -d for this.
*I think it should be possible to define the PANEL monitor values in the
xorg.conf file*
What do/others think about this?
In your case, yes.
And for CONNECTOR_PANEL (a PANEL without ATOMBIOS and without EDID) it's
even worse, because the process for using a "configuredmonitor" is never
hit:
if (! rhdPtr->randr) {
/* Pick anything for now */
if (!rhdModeLayoutSelect(rhdPtr)) {
-> rhdModeLayoutSelect calls RHDMonitorInit() which will fail for PANEL
(and no other monitors are connected), so the we goto error1 and never
use the pre-configured monitor for PANEL. But maybe that's intented?
xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
"Failed to detect a connected monitor\n");
goto error1;
}
Yes, without AtomBIOS we don't know, what sort of panel is connected.
This is simply not supported (yet).
It would be possible to add this:
There are two possibilities:
1. You specify the size of the panel (and optionally a frequency).
We would use gtf to calculate a mode (with reduced blanking).
2. You specify the entire mode. This way you could also support
odd panels. I'm not sure if there are any use cases for this
and if so if we can expect from the user to obtain the information
needed.
ATM I'd opt for 1. from there we should look how far we get.
Independently we should investigate if it is possible to obtain
an AtomBIOS on an EFI booted macbook.
Cheers,
Egbert.
--
Cheers,Greetz
Egbert.
thomas
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx
| < Previous | Next > |