xorg.conf nx7000 dual head problem

Wed Dec 1 20:06:36 UTC 2004

On Mon, Nov 29, 2004 at 08:41:22AM +0200, Korpelainen, Seppo wrote:

> Update:
> >This configuration is working ok for me otherwise, but
> >for some unknown reason I can't use mode 5 as the default
> >runlevel in the /etc/inittab anymore. The boot process will 'hang'
> >in the end of the rc5.d scripts and never opens the gdm screen.
> >
> >If I set the runlevel at 3, login in text mode and
> >use "startx" to start X everything works ok.

> I removed the "rhgb" option from the /etc/grub.conf and
> now I can use runlevel 5 in inittab.

> The same evidence is available here:
> http://www.fedoraforum.org/forum/showthread.php?t=27513&page=2

	Looks like a number of us are running into the same thing.
Mine is on a Dell D600 laptop with a Radeon Mobility 9000 controller.

> I lost some eye candy during the boot, but I prefer the text mode
> anyways.

	You may yet have lost more than you thought and you may be left
scratching your head figuring out WTF broke if you accidentally stumble
into the booby trap that's left (virtual console switching).

	What I found, diagnosing my problem, is that it appears that
switching virtual consoles seem to be broken if you have your current
X screen configured in any sort of "multi-head" mode (clone, Xinerama,
or simple multiple screens).  What this means is that X is fine coming
up in a multiheaded mode but, if for any reason, if you or the system
switches virtual consoles, you're dead.  The "exiting" X server hangs
and burns CPU time (you can remotely ssh to the box and do a top and
find X hammering the CPU).

	The reason it fails with rhgb is that most people simply have their
xorg.org file default to a multiheaded mode if they've got multiple screens,
which means rhgb is in the multihead mode.  That then hangs when gdm attempts
to switch virtual consoles to bring up the first real X server.  So, you
evade the problem when you disable rhgb because your main X session becomes
the first multihead X session and you're cool because X is never "leaving"
one virtual console to switch to another.  That's cool as long as you
NEVER switch virtual consoles, accidentally or intentionally.

	The problem can also be evaded by leaving the "Default Layout"
alone and creating a new "MultiHead" layout following it.  Then, in
/etc/X11/gdm/gdm.conf you add "-layout MultiHead" to the server command.
That way, rhgb comes up in "normal" (i.e. single head) mode (or something
similar) and then gdm switches to your multihead mode of choice.

	A real problem with BOTH options evading the problem is that virtual
consoles switching IS STILL BROKEN.  Try hitting "Cntrl-Alt-Fn" and see
what happens.  It would be my guess that you will be toast (save your work
before trying this).  Doesn't matter if you are going to a console screen
or another GDM/X session.  The one you are switching from hangs and starts
burning CPU time.  You can ssh into the system from another system, kill
that X process (-QUIT seems to do it, -HUP and -TERM do not) and then do
a "gdm-restart" and the screen will recover, though you've lost your session.

	I also found that I can have the first GDM session start "standard"
(as long as rhgb is booting "standard") and a second one start multihead,
and that works too.  You just can't switch from the second one to the first
one (which makes the first one rather useless).  That all DID work under
FC2.  If you configure a multihead GDM server on anything other than the
LAST one, GDM is going to switch to another VC and you will be left dead,
staring at the login screen of the first VC with multiple heads.

	I was afraid it was something peculiar that had happened with
the Radeon driver code, but now it sounds like it's much more generic to
the multihead logic in the X server.

> -- seppo

> -----------------------------------------
> ============================================================  The
> information contained in this message may be privileged   and confidential
> and protected from disclosure.  If the   reader of this message is not the
> intended recipient, or an   employee or agent responsible for delivering
> this message to   the intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this   communication is
> strictly prohibited. If you have received   this communication in error,
> please notify us immediately by   replying to the message and deleting it
> from your computer.    Thank you.  Tellabs
> ============================================================
> 
> 
> -- 
> fedora-list mailing list
> fedora-list at redhat.com
> To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw at WittsEnd.com
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20041201/d1624178/attachment-0001.sig>