-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Jul 12, 2007, at 05:53, Andreas Moschos wrote:

>>
>> > it seems like a modeline issue to me but after using:
>> > ModeLine "1440x900" 96.2 1440 1504 1536 1760 900 903 906 912
>> > had the same results.
>> > iBookHacks is enabled.
>> =A0
>> Well it was not a modeline issue.
>>
>> Unfortunately the radeon driver heavily depends on reading pll
>> parameters from the firmware ROM which currently doesn't work on=20
>> macppc
>> ( not sure why - either the driver doesn't like OpenFirmware or it
>> doesn't find the ROM )
>> As an ugly workaround you can use the wsfb driver - that will be =
stuck
>> in whatever the console used and won't have acceleration but it =
should
>> at least work.
>> =A0
> using a section "Device" with wsfb did not work for me.Log file said:
> (II) wsfb: driver for wsdisplay framebuffer: wsfb
> (II) Primary Device is: PCI 00:10:0
> (EE) No devices detected
> =A0
> Note that BusID is "PCI:0:16:0" for radeon in the config file
> Maybe a misconfiguration from me?

What does your device section look like? wsfb doesn't need any=20
additional parameters ( no bus ID or anything like that - it doesn't=20
know or care about buses, instead it will try to use whatever can be=20
mapped via ttyE0 )
And you can easily check if your BusID is right - pcictl pci0 dump will=20=

list all PCI devices that can be found on the 1st PCI host bridge, on=20
Macs that's usually the AGP port. On the other hand, if the BusID was=20
wrong the radeon driver would have complained too instead of messing=20
with the chip.

>> > =A0i thought of using a current kernel but i only get coredumps of=20=

>> XFree
>> > with black screens.
>>
>> That's weird - where and how does it crash?
>> =A0
> Let me rephrase.It actuall lives me with a blank screen and i find a=20=

> coredump of XFree.I did not try a remote session on this one.

Even weirder - either XFree86 crashed very early or very late, by=20
default it will install a signal handler to catch events leading to=20
coredumps and does its own little dance instead of dumping core which=20
leads to annoying deadlocks sometimes ( if the signal handler=20
crashes... )

> But it finally worked! I stopped the wsmoused from running and=A0X=20
> started succesfully, note that it works with both the manually=20
> configured Mode and without it :)

I had a lot of trouble with wsmoused on macppc, for some reason it=20
doesn't seem to like bitmapped wsdisplays even though it shouldn't know=20=

or care about the difference, or it's a bug I introduced with machfb=20
which got cargo-culted to all the others ;)

> So it does understand the widescreen format.

Nice :)
For the records - please post your dmesg and XF86Config along with an=20
exact model name so the next guy in this situation can easily google up=20=

your solution.

> One minor issue is that at the areas where i can see garbage under=20
> wscons i see something like "snow" under X but if i use an xterm at=20
> that area and issue a top or a clear it goes away and comes back=20
> gradually after a few moments!

That looks like a misdetected framebuffer memory size or something=20
messes in fb memory where it shouldn't. Could you send me your=20
XFree86.0.log in a private message?
And - does the garbage show up in screenshots? If it does please send=20
me one, to understand the problem I need to see it.

>> > =A0i also have issues with the output of the wscons using the =
curret
>> > kernel.The first 20 lines (counting from the top of the panel) are=20=

>> so
>> > meshed up i can see nothing (on all the screens).
>>
>> Radeonfb has trouble on R3xx and newer, unfortunately nobody with
>> access to such hardware did any debugging work that I'm aware of so=20=

>> far
>> ( all I have is the RV280 in my iBook G4 which works fine )
>> =A0
> if you think a debugging procedure could be started by asking me some=20=

> data which i could get back to you please let me now.Don't pick=20
> lemons.

Ok, please mail me the following things privately:
- - dmesg output
- - your XF86Config
- - your XFree86.0.log
- - ofctl -p output
that should give me a pretty good idea of what your hardware is like=20
and what X and radeonfb are trying to do with it.

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBRpYlkMpnzkX8Yg2nAQJKawf/aMbvcHMs86vYbpF+eOoFANMFSFozJH9U
WzmlXJXW8987345v5pt/MTlviPGsj7xRJHLqBVmELtGRnRnPj783LrwaTalTn8KC
4urBnzhPC4naeFa6qrTH0XQ2vruOJJVwiG/ZD73R6l99redClHn/owBT4EeZ+8Fv
W5j+MtgvQQ0DMHycpio2DsBgqwx1NOtIanv6/NBwMJykv41v7HWw1+rcLkr7rQZs
Ak0Y5Bygq+afOBehvh2teyA9yZ23gkdiXK/JfaW5yHhDYfBW+5YeIPyXDy+myxMb
pa9wqcHe0nZfY5r/kX9qCfR/Aybpccay0anPHZqiB3d7ZgwPkV53CQ=3D=3D
=3Dd5pg
-----END PGP SIGNATURE-----