patch to get latest XFree 4.0 snapshot (xf3918) to workonppcwithr128

[Michel Danzer]

--- Michael Schmitz <schmitz at opal.biophys.uni-duesseldorf.de> wrote:

> > > Possibly; I've also seen the X server convert XFree mode lines into
> > > fbdev timings, thereby overwriting the 565 with 000. Doesn't hurt for
16
> > > bits, only for 32 bits.
> >
> > Doesn't hurt for probing, but maybe for the ioctl?
>
> The ioctl has been disabled long time ago.

I meant when you hadn't disabled it. It hung there at the time, right? Now a
hang in an ioctl is a kernel bug, or am I missing something?


> I'll get back to poking around in there as soon as I can figure out how to
> see the kernel messages (i.e. how to switch back to the text console fast
> enough, or never let the X server switch to VT 7 in the first place).

A remote machine might be handy...


> Now I can't get beyond xf86HandleColormaps(). Another ioctl that barfs on
> me, perhaps.

Well possible, FBIOPUTCMAP in fbdevHWLoadPalette.

I don't understand the code there...

BTW I've just discovered that the fbdev driver sets the weight explicitly to
{0,0,0}... now I'm (really ;) confused.


> I guess it all boils down to PCI messups.

How do you come to this conclusion? Why should it influence ioctls?


Michel

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/