[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Continuing Annoyances...

--- "C.M. Connelly" <c@eskimo.com> 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

>    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.


"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.

Reply to: