[4949] in testers
8-bit background color, Sparc4 bitmaps, Linux console path
daemon@ATHENA.MIT.EDU (Mitchell E Berger)
Fri Jul 6 04:39:26 2001
Message-Id: <200107060839.EAA09557@byte-me.mit.edu>
To: testers@MIT.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 06 Jul 2001 04:39:23 -0400
From: Mitchell E Berger <mitchb@MIT.EDU>
Three completely separate bugs here...
Sparc4 bitmaps
==============
I noticed last night that the two running 9.0 Sparc4s in W92 weren't
displaying any of the xlogin bitmaps. I don't know if this is already known
or why it's happening. Initially I thought that the bewitching forces of the
full moon might have been at work, but midnight passed, I restarted xlogin,
and still no bitmaps.
Linux console path
==================
When performing a console login on a Linux box, PATH is not completely set by
the time your .environment is sourced. Thus, although any adds you have there
work just fine, aklog gets a command not found error. This is not the case
for X logins on Linux or for any logins on Suns or SGIs. Were I thinking more
clearly, I might be able to find what's different about Linux console logins,
but likely someone reading this will know immediately what the problem is. If
nobody replies about this, I'll try looking at the source closer tomorrow.
8-bit background color
======================
It wasn't really apparent before, but when logging in on an 8-bit display
(like a Sparc{Classic,4,5}) the background color Gnome sets is not the one we
specified; it's a darker purple-blue. The 8-bit display, however, is
perfectly capable of displaying the right color. I discovered this because
after installing my new xlogin, which sets the root window to the correct blue
background, when I logged in the color very noticeably changed. If you have
such a display, you can see the problem by logging in to your machine and
typing 'xsetroot -solid "#5e738f"' and watching your background change to the
"correct" color. For those curious, no, it has no name, just a hex number.
I came to an exciting realization about this and the whole 8-bit background
color problem (the lime green appearances included)... once my xlogin patch is
taken, there's no need for Gnome to set the color, as xlogin will have already
done it correctly! Previously (pre 9.0) we've never had another program set
the background because we didn't need to - it was already the way it was going
to stay while xlogin was running. This will shortly be true again. What
amounts to unchecking the "Use Gnome to set the background" box in the
background-properties capplet as the default is, I believe, a one-line patch.
Disabling Gnome's background color setting has the following good effects:
- It doesn't screw anything up, as the background is already correct.
- It speeds logins a little since there's one less thing to do on login.
- It leaves the correct colors as the default if a user enables the Gnome
background setting for themselves.
- It fixes the 8-bit color problem because if Gnome doesn't touch your root
window, it can't screw it up!
It's possible that scrapping my panel/sawfish startup order changing patch and
accepting Greg's sawfish patch and my xlogin and background-properties patches
will fix the last of the really annoying graphical login problems.
I've tested this and found that it works on my Classic. I'll submit a patch
for it once I test it on a current Sparc, O2, and Optiplex, and after xlogin
gets taken, unless there's a reason not to.
Mitch
