> Before I file more bug reports, I thought I'd see whether other
> people are having the same issues I'm having.
Wow, many problems :-)
> 1. gdm locks up the keyboard when started at boot time.
>
> X starts, gdm comes up, the mouse works, but you can't type.
> Which also means you can't switch to a virtual terminal to stop
> and restart gdm. (Luckily we have three Unix machines in our
> house, so it's only annoying to have to telnet or ssh in and
> fix the problem.)
I have the same effect with xdm on an athlon system. Dunno what the
problems is. Start X on the console with startx
> 2. Frame buffer console annoyances.
>
> When my machine starts up, the text is red on a black screen.
^^^^^^^^^^^^^^^^^^^^^^ bah!
> We run fbset from a script in /etc/rc.boot to correct this
> problem. The text turns to white on black (hooray), but the
> cursor is invisible. Other virtual terminals display in
> various funky colors. X starts (with gdm) at the wrong
> resolution.
>
> #!/bin/sh
> # /etc/rc.boot/0fbdev
> #
> # Sets resolution and refresh rate for framebuffer.
> # 11 Jul 1999 by MEO
> #
>
> FBSET=/usr/sbin/fbset
>
> # If the serial executable has been removed abort the configuration
> [ -x ${FBSET} ] || exit 0
>
> echo -n "Configuring frame buffer..."
>
> # fbset --all 1024x768-75
> ${FBSET} -a -x -depth 16 1152x864-80
>
> echo "done."
Known problem. At startup only the first console exists. So the
/etc/rc.boot/0fbdev can only initialize this one console ( -a is
correct ... but you have only one).
How does it xdm? Is S99 a special entry? no, don't think so
We have to wait that all 6 (or more) getty's exists.
A short delay for this is a bad idea, an new entry into the
/etc/inittab file isn't also good.
I must write two little scripts, one configure-fb (mainly for the res.), and
one that will wait for all virt.-consoles (and to restart gpm).
> If I quit gdm (and the X server) and run the same fbset command
> line from the /etc/rc.boot/0fbdev script by hand, then restart
> gdm, I can sometimes get X to come up in the right resolution
Yes, then all virtual-consoles exists, also the one for X11.
> (sometimes I need to run fbset by hand while X is running, then
> quit and restart gdm). Virtual terminals are white text on
> black background, but no matter what I do, the cursor remains
> invisible.
Ohh, dunno why.
> Oh, and the resolution actually used seems to be 1152x870-75.
> (Or so fbset reports when run with no arguments.) Note that X
> misbehaves no matter what fbset reports until after the magical
> manual fbsets.
Is it possible the -depth 16 ??
>
> 3. fdutils don't work on PowerMacs?
>
> it claims to be obsolete and recommends superformat.
Yes, superformat is only for i386 or for powerpc's with intel-like
hardware.
>
> 5. Does gpm work on PowerMacs? If so, how should it be
> configured?
>
> I have gpm running on my system, as installed from the base
> install (I assume) and with the arguments it came with
>
> device=/dev/adbmouse
> responsiveness=
> type=ms
^^ ? busmice or so
> append="-l \"a-zA-Z0-9_.:~/\300-\326\330-\366\370-\377\""
>
> It appears to have no effect in console applications that seem
> like they might use its features, however.
BTW: add this to your script:
# fbset --all 1024x768-75
${FBSET} -a -x -depth 16 1152x864-80
/etc/init.d/gpm restart
echo "done."
> 6. Recent kernels don't work.
>
> 2.2.13 and 2.2.14 (any prerelease patch level -- all from
> standard kernel sources (i.e., *not* vger kernel source -- and
> where is that, these days, anyway?) don't produce functional
> kernels. They cause a machine check in kernel mode, ``probably
> due to mm fault with mmu off''.
Bad news. I hope we can fix it.
vger itself is closed. Try this:
#!/bin/sh
#
cvs -d :pserver:[EMAIL PROTECTED]:/cvs/linux co linux
#cvs -d :pserver:[EMAIL PROTECTED]:/cvs/linux co -rlinux_2_2 linux
I hope this helps a little bit.
MfG,
Hartmut
