(I'm going to do a mass reply here -- please bear with me. Also,
thanks for the responses!)
GU> Geert Uytterhoeven <[EMAIL PROTECTED]>
HK> [EMAIL PROTECTED] (Hartmut Koptein)
KP> Kevin Puetz <[EMAIL PROTECTED]>
MD> Michel "Dänzer" <[EMAIL PROTECTED]>
NO> Nathan Olsen <[EMAIL PROTECTED]>
1. gdm locks up the keyboard when started at boot time.
HK> I have the same effect with xdm on an athlon system. Dunno
HK> what the problems is. Start X on the console with startx
I like having the login panel (even though I almost never see it).
Besides, if it's broken, we should try to get it fixed, right?
NO> I've experienced this problem from time to time as well. I
NO> have managed to "fix" this by hitting "iconify" and
NO> opening/closing the loggin window a couple of times and
NO> maybe even clicking my mouse over the area where the
NO> characters you type appear and then it seems to work.
I'll try this trick next time -- it can't hurt, right?
GU> I used to have a similar problem. It's gone since I
GU> upgraded gdm (2.0-0.beta4.5 now). I still have a different
GU> problem: on one out of 5 boot ups, the X server locks up
GU> after I typed a few characters in the login widget. Killing
GU> X remotely fixes it. I didn't suffer from that problem with
GU> xdm.
Hmm. I'm running gdm 2.0-0.beta4.5 now. I remember seeing a
report about the problem on the bug tracking system, and a claim
(or hope?) that it had been solved, but all the older bug reports
seem to have been cleaned out of the system now.
One thing I have noticed lately is that there seem to be several
gdm processes running at times. Doesn't seem like a good thing to
me.
I haven't seen the type a bit and then lock up problem myself.
Maybe I got the start up and lock up problem instead? ;-|
HK> BTW: add this to your script:
HK> # fbset --all 1024x768-75
HK> ${FBSET} -a -x -depth 16 1152x864-80
HK>
HK> /etc/init.d/gpm restart
HK>
HK> echo "done."
I think Hartmut meant gdm here, rather than gpm (please correct me
if I'm wrong!). With that change, and with the addition of a link
to the script in /etc/rc2.d (as S99fbdev), gdm does in fact
restart and thereby restart X so that it ends up using the correct
resolution. Unfortunately, it also locks up the keyboard. The
iconize/uniconize trick doesn't seem to work for me, so back to
the drawing board. (I will file a bug report.)
2. Frame buffer console annoyances.
HK> Known problem. At startup only the first console
HK> exists. So the /etc/rc.boot/0fbdev can only initialize this
HK> one console ( -a is correct ... but you have only one).
HK>
HK> How does it xdm? Is S99 a special entry? no, don't think
HK> so We have to wait that all 6 (or more) getty's exists.
HK>
HK> A short delay for this is a bad idea, an new entry into the
HK> /etc/inittab file isn't also good.
HK>
HK> I must write two little scripts, one configure-fb (mainly
HK> for the res.), and one that will wait for all
HK> virt.-consoles (and to restart gpm).
Me> Oh, and the resolution actually used seems to be
Me> 1152x870-75. (Or so fbset reports when run with no
Me> arguments.) Note that X misbehaves no matter what fbset
Me> reports until after the magical manual fbsets.
HK> Is it possible the -depth 16 ??
Dunno. I did (for the longest time) have weird color problems
with some of the GL xscreensaver hacks (notably the endless
staircase one and the impossible wooden cube one) -- they were
tinted a weird green. That got fixed when I added the line
``Depth 16'' to my /etc/X11/XF86Config.
MD> This sounds like a framebuffer device (fbdev)
MD> problem. Which one are you using?
I'm not sure what you're asking. Package is xserver-fbdev,
version 3.3.5-1.1. The machine has ``Platinum'' video (it's a
PowerComputing PowerCenter 132, which uses the Catalyst
motherboard design Apple licensed to clones -- weirdly, although
it's supposed to be a 7200 clone, and MacOS sees it as a 7200,
Linux sees it as a 7300 (according to /proc/cpu)). I just noticed
/proc/fb, which says ``0 platinum''.
MD> As your fbdev seems to support mode changes, you can use
MD> custom modes in your XF86Config. fbset -x gives you a mode
MD> definition which you can insert directly into that file.
Aha. That's neat. I'll try that and see if it helps.
3. fdutils don't work on PowerMacs?
HK> Yes, superformat is only for i386 or for powerpc's with
HK> intel-like hardware.
So there's no way to format diskettes on a PowerMac system? That
seems wrong....
5. Does gpm work on PowerMacs? If so, how should it be
configured?
Busmouse (bm) it was -- I tried PS/2, as well, but that didn't
work (just for newer machines, I guess).
Also, someone wondered if the gpm mouse cursor wouldn't be
invisible when the regular cursor is invisible. From what I can
see, the mouse and text cursors are independent. The mouse cursor
appears as a white block even when the text cursor is black
(invisible) or some other (non-white) color.
6. Recent kernels don't work.
HK> vger itself is closed. Try this:
HK>
HK> #!/bin/sh
HK> #
HK> cvs -d :pserver:[EMAIL PROTECTED]:/cvs/linux co linux
HK> #cvs -d :pserver:[EMAIL PROTECTED]:/cvs/linux co
HK> -rlinux_2_2 linux
I knew vger was gone, but (of course) I couldn't find my notes on
where the CVS archive had moved. Also, when I did manage to find
some pointers, it seemed like the Web site part of
cvs.on.openprojects.net was down (claiming to be temporarily down
while moving machines or something, ca. October, 1999).
Kevin says (to Nathan Olsen)
KP> I got it to compile by adding #include <dma.h> to the file
KP> that fails, but it had the keymap from hell (and I couldn't
KP> figure out which keymap that was). i386/qwerty/defmap was
KP> close and made the letters work, but other things were not
KP> right :-(
I'm guessing this is a problem for iMacs and similar machines? I
haven't seen this one on my system. (I do see that it's
complaining about a multiple definition of serial_console_init --
defined in both
General setup ->
Support for PowerMac serial ports ->
Support for console on serial port
and
Character devices ->
Standard/generic (dumb) serial support ->
Support for console on serial port
At a guess, perhaps I shouldn't have the Standard/generic (dumb)
serial support checked, although it doesn't seem like you should
be asked about that if you've already selected Support for
PowerMac serial ports.)
KP> Also, Debian for some reason does not have
KP> /usr/include/linux a symlink into the kernel source
KP> (linux/include/linux). You'll also have to fix that for the
KP> kernel to build correctly.
Hmm. Unless something in the mrproper target takes care of this
link, I've never had that link, and (up 'til recently) never had a
problem compiling a working kernel. (I actually had 2.2.13
compiled and working fine until I tried compiling one of the
2.2.14 prereleases, after which the 2.2.13 kernel gave a similar
machine check on startup.) I do remember having to make that link
on an i386 machine I had a few years ago, though. Also, as a
bunch of other people have pointed out, Linus just threw a fit
about such links.
After some more experimentation (with the 2.2.14 kernel sources) I
was able to get the kernel to compile. The compilation problem
seems to have been related to the two separate serial port support
options. I also discovered that some of my other problems (the
machine check) seemed to be related to not cleaning out all the
old object files that were created as a result of choosing both
serial port options. After cleaning up (with make clean) and
recompiling, I got a kernel that booted, but appears to have a
slew of problems related to, you got it, the serial port support.
Apparently that was one of the recent changes to the PowerPC code.
Finally, I have one major problem that I didn't mention in my last
message, because I couldn't figure out what was causing it (as it
happens, I fixed it Tuesday night):
After trying the 2.2.14pre18 kernel (which failed as I mentioned
before), I discovered that when I logged in everything took
forever. GNOME (and WindowMaker) would eventually start, but only
after an agonizing wait (hit return and go have a cup of coffee).
And things launched from the Panel would take a similar amount of
time, such as starting a new gnome-terminal. Doing a top (while
logged in from another machine) would show the newly launched
applications using huge amounts of resources, but essentially just
sitting there.
I tried replacing my ~/.gnome directory from backups (I keep a few
compressed tar files containing known working versions of my
~/.gnome and ~/GNUstep directories after some unpleasant
experiences in the early days), then wiping ~/.gnome entirely
(leaving me with Enlightenment, but all the same GNOME problems).
I finally restored my ~/.gnome directory from a recent backup and
decided to try to live with it until I could figure the problem
out (or find someone else who had).
Tuesday night, I was inspired, and after trying to launch some
gnome-terminals, I tried launching an xterm from the
mini-commander applet. It popped up immediately. Hmm. Then I
remembered the strace command, and opened a new xterm (with a
scroll bar, this time), and typed ``strace gnome-terminal''. It
turned out that gnome-terminal was getting stuck while trying to
read ~/.esd_auth. Hmm. On a whim, I killed esd, and bam! Up
came the gnome-terminal!
But GNOME would relaunch esd after it was killed, bringing the
back the wait. I checked to see if I had the ``Enable sound
server startup option'' checked in the GNOME Control Center sound
panel (that required me to kill esd twice -- once for gnomecc and
once again for the sound-properties applet). Nope.
So I checked to see if I had the most recent esound. Yes. Except
that there was a newer source package, so I did an apt-get source
-b esound, the source was downloaded, built, and packaged into
debs, I installed the debs, and voila! things work again.
Anyway, thanks much for the help you've provided so far. Any more
hints on any of the remaining questions would be greatly
appreciated.
C.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Behind the counter a boy with a shaven head stared vacantly into space,
a dozen spikes of microsoft protruding from the socket behind his ear.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
C.M. Connelly [EMAIL PROTECTED] SHC, DS
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
