[Call for Testing] X.org 7.5 for FreeBSD

[Robert Noland]

On Sun, 2010-04-04 at 10:00 +1000, Peter Jeremy wrote:
> On 2010-Mar-11 14:44:14 +0100, Martin Wilke <miwi at FreeBSD.org> wrote:
> >Please report any problems and issus to x11 (at) FreeBSD.org.
> 
> Another data point (sorry for the delay):
> 
> FreeBSD server.vk2pj.dyndns.org 8.0-STABLE FreeBSD 8.0-STABLE #1: Wed Jan 27 06:55:10 EST 2010     root at server.vk2pj.dyndns.org:/var/obj/usr/src/sys/server amd64
> 
> (--) PCI:*(0:1:0:0) 1002:94c3:1458:2192 ATI Technologies Inc RV610 video device [Radeon HD 2400 PRO] rev 0, Mem @ 0xd0000000/268435456, 0xfdfe0000/65536, I/O @ 0x0000de00/256, BIOS @ 0x????????/65536
> 
> Good news:  X starts and stops cleanly and VTY switching works.
> 
> Problems:
> 1) DRI (and apparently EXA) report as disabled:
> (EE) RADEON(0): [pci] Out of memory (-12)
> (EE) RADEON(0): [pci] PCI failed to initialize. Disabling the DRI.
> (WW) RADEON(0): Direct rendering disabled
> (EE) RADEON(0): Acceleration initialization failed
> (II) RADEON(0): Acceleration disabled
> 
> There was a thread in mid-February suggesting that this is caused by
> a lack of contiguous RAM.  I've tried running a process that just
> allocates 1GB RAM and then exits (leaving me with >900MB free space).
> Whilst this doesn't guarantee any large contiguous RAM blocks, it
> seems odd that there wouldn't be any.

I thought that I had a patch posted that addressed both this issue as
well as the mapping overlap, but it looks like i never posted the
reworked scatter gather allocation code.  What kernel are you running?
The new code interacts directly with the VM system and eliminates the
requirement to have large chunks of contiguous memory to back the GART.

> 2) mplayer plays video at about 2-3 times the correct rate and firefox-3.5
>    also plays HTML5 video excessively fast.

This is usually due to your audio hardware.  Many radeons have HDMI
ports, but in order to actually set the hardware up properly, you have
to use the radeonhd driver with the Audio option set.  mplayer appears
to sync it's framerate to the audio and when the codec isn't initialized
properly, it just plays full steam.  If you aren't actually using HDMI,
then all you need to do is set hw.snd.default_unit to point to your
correct codec.  Once sound works, mplayer should play at the correct
rate.

robert.

> I'm not certain if this is Xorg or something else and will need to
> investigate further.
> 
> Any suggestions on either of these?

-- 
Robert Noland <rnoland at FreeBSD.org>
FreeBSD