--- "C.M. Connelly" <[EMAIL PROTECTED]> wrote:
> 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!).
He did mean gpm. This is needed because gpm doesn't notice changes of the
console window size, so if you e.g. change to a bigger resolution, you can't
move the mouse pointer beyond the former size.
> 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.
The depth in X is independent from the one in console (at least if the fbdev
can change modes, which seems to be the case with yours). Have you tried
depth 8 in console? This is recommended, as the console has only 16 colors
anyway.
> 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.
It would make X resolution independent from console resolution as well.
> 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).
> [...]
>
> 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.
I also have problems with GNOME taking ages to start up, I seem to have
tracked it down to a DNS lookup, which bind blocks for quite some time when
the network is down. I already suspected esd, but I was not sure. Hope this
helps anyone to figure out the real problem.
Michel
=====
"Software is like sex; it's better when it's free"
-- Linus Torvalds
"If you continue running Windows, your system may become unstable."
-- Windows 95 BSOD
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
