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

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

quoted

quoted

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

quoted

quoted

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/