Mailinglist Archive: radeonhd (333 mails)
| < Previous | Next > |
Re: [radeonhd] HDMI support including Audio
- From: Christian König <deathsimple@xxxxxxxxxxx>
- Date: Sat, 11 Oct 2008 00:24:50 +0200
- Message-id: <1223677490.7995.36.camel@zweiundvierzig>
Am Freitag, den 10.10.2008, 12:44 +1300 schrieb Michael Cree:
remember correctly gcc should (depending on compiler options) take care
of this. I'm working with different operating systems and cpu
architectures including solaris and sparc all day, and know the
underlying problem. My best bet would be the x86 emulation, since i
don't really know how this is implemented on sparc.
(http://www.hdmi.org/download/HDMISpecification13a.pdf), unlike most of
the vesa standards this one is available for free.
my RV630 in a motherboard with onboard 780G. If the RV630 isn't selected
as primary video device in the BIOS it doesn't get initialized at POST,
resulting in all kind of weired behavior (including wrong colors, all
zeros in the 7300-73ff range, or even no picture at all).
That's something i really can't do anything about without some good
atomBIOS documentation, but since this bug will affect most of the
people trying to get more than one card into a motherboard it should get
a little bit priority.
Bye, Christian.
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx
I also noted a number of "unaligned trap" warnings appearing in theThe patch should not introduce any misaligned memory access, if i
kernel log due to the Xorg process. I don't recall seeing them prior
to this date, but will need to investigate further to verify whether
they are due to the latest radeonhd plus audio. The unaligned traps,
on Alpha, are not a show stopper, it just means the kernel emulated a
misaligned memory access the CPU couldn't perform. The main detriment
is a large performance hit. But I understand that on the Sparc
platform misaligned accesses result in shutting down the process that
generated them so ultimately, one should avoid them, if you want
generally portable code. I will investigate further to verify whether
the radeonhd driver is causing them, or whether it is something else
in Xorg.
remember correctly gcc should (depending on compiler options) take care
of this. I'm working with different operating systems and cpu
architectures including solaris and sparc all day, and know the
underlying problem. My best bet would be the x86 emulation, since i
don't really know how this is implemented on sparc.
Thanks for the clarification of DVI versus HDMI.If you want some more infos about this take a look the HDMI Standard
(http://www.hdmi.org/download/HDMISpecification13a.pdf), unlike most of
the vesa standards this one is available for free.
Running rhd_dump is rather boring. It returns zeros only. I presumeOh, oh that's really, really bad. I can reproduce the problem if i put
that is not expected. Output follows
my RV630 in a motherboard with onboard 780G. If the RV630 isn't selected
as primary video device in the BIOS it doesn't get initialized at POST,
resulting in all kind of weired behavior (including wrong colors, all
zeros in the 7300-73ff range, or even no picture at all).
That's something i really can't do anything about without some good
atomBIOS documentation, but since this bug will affect most of the
people trying to get more than one card into a motherboard it should get
a little bit priority.
Bye, Christian.
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx
| < Previous | Next > |