On Sat, 17 Apr 2004 20:12:08 +0200 Ronald van der Pol
<Ronald.vanderPol@rvdp.org>:

> I get the X11 background and a cursor. But also horizontal lines/
> disturbances.

Harumph.

Horizontal lines/disturbances.  Exactly what we see on our iBook. But
X works for us, if you don't mind unreadability.  We get screens,
cursors that move, and such.

You might want to revue an email I made on this subject 9 Mar 2004
17:50:01 -0000 Subject: Fwd: Re: getting X11 on the 9500 Sender:
port-macppc-owner@NetBSD.org.  The main bone of contention was getting
past the "xf86MapVidMem: could not mmap screen" X ppc error (which you
obviously did.  Did you use the NetBSD X, or the XFree distribution
direct, or did you use my patch?  I'm curious to see if this has been
corrected.), but I also mentioned the horizontal lines.

If I understand the workings of flat panels correctly, the horizontal
sync et. al. timings don't apply, because the pixels are individually
clocked.  The vertical refresh might, if it's too fast for the
panel.

However, there's another set of timings that I think are the problem.
These are the PLL clocks, which set the rate at which the flat panel
pixels are updated.

The X chip driver typically sets up the PLL clock rates depending on:
1) what the video BIOS sets them to when called _by_ the X chip driver,
2) what the X chip driver finds in the video BIOS, or, failing the
first two, 3) what the X chip driver thinks is the correct values.

Unfortunately, because the iBook is not a PeeCee, 1)the X chip driver
does not even attempt to call the video BIOS, and 2)the X chip driver
is confused by the video firmware it does find.  So, the X chip driver
attempts to use its own PLL values.

But, the the X chip driver doesn't have an individualized,
particularized set of values for the particular video chip involved
here, the ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility
7500].  So, it uses a general default.

In my opinion, the X chip driver would be better off not changing the
PLL values at all.  We tried stopping the X chip driver from doing
that, but we either failed, or not changing the PLL values has no
effect, for we weren't able to change the display at all.

So there we sit.  What to do?

1.  Figure out if the video firmware is callable?  It's probably some
    form of Open Firmware stuff.

2.  Figure out if values are stored in video OF some where, or if it's
    in the PeeCee format and we're once again being whacked by the
    Great Little Endian Fraud?

3.  Guess what the proper values are, and plug them into the Driver
    table?

4.  Punt to the XFree (ATI specifically) guys?

Dunno.  Running out of time.  But I'd love to get our iBook running
X properly.

> The background covers all of the screen (not only
> part on it). The cursor does not move. With ps(1) I do not see
> the Xserver running. I think it exited,

Seems reasonable.  Evidently your screens couldn't be started, (or
maybe X quit earlier.  The RADEON driver doesn't clean up well, which
means that our iBook screen is Really Messed Up when X exits.  In your
case X seems to be abruptly killed or exited, leaving what it made in
the video chip:  frozen cursor, etc, etc.

Yes, we have a XF86Config file that mostly works -- excepting that it
might accept PLL values, if we knew what they were.  It has references
to flat panel stuff, which, BTW, you can only devine if you read the X
RADEON driver code. Unfortunately, the file is on the iBook right now,
but the iBook is turned off, the fellow who actually got the iBook to
boot and up doesn't work weekends, and I have forgotten the boot
incantations.

> but none of the logs show
> any evidence of that.
> 
>         rvdp

But it's strange that nothing's logged.

Did you look at /var/log/XFree86.*.log?  Try an ls -altr on /var/log
to see if an alternate log was written.  Also, did you use xinit? If
so, you can also log like:

    xinit 2>>my.favorite.logfile.name

-Mike