Announcement

Collapse
No announcement yet.

bulletproofX failsafeX and bad behavior

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    bulletproofX failsafeX and bad behavior

    Hello,

    I have installed Maverick kubuntu on a quite modern machine with two gf9500 cards. I activated the nvidia driver and then tried to configure it to get it running as a twin-seat system.

    This works now if is start kde manually and I can login.

    After each reboot now, that failsafeX-nonsense (and i say nonsense, because it hinders to get to the console to do the repairs if something breaks) begins to start. If I then say switch to console, I get there only to be kicked back to failsafeX after 2-3 Seconds for another try to get to the console, now longer.

    The interesting part ist now, that while staying there after so 5-10 Seconds kdm starts up and I get the login screen.

    So now, I don't know how the kubuntu people implemented that, but it doesn't work.

    It seems that my kdm startup takes a little bit longer than some timeout for failsafe X (or logparsing??). So now, I would like to know, how I can either disable failsafeX or changing timeouts/behavior.

    The tip with /etc/gdm/gdm.conf ist as far as I see not that helpful because there is no such file on my system...

    Christian

    #2
    Re: bulletproofX failsafeX and bad behavior

    Originally posted by boronk


    The tip with /etc/gdm/gdm.conf ist as far as I see not that helpful because there is no such file on my system...
    True, but you should have a /etc/kde4/kdm/ directory -- KDE uses the K Display Manager, not gdm. But I'm not aware of any recommendation to modify any of the files that you find there.

    Also, there should be information in the log file /var/log/Xorg.0.log, regarding failure of X to start (if the problem is an X problem).

    Comment


      #3
      Re: bulletproofX failsafeX and bad behavior

      Yes, indeed. Though you know, that failsafeX must use some of that gdm directory. The concerning kdmrc file shows no parameter which can change the failsafeX timeout.

      In addition to that, X works.

      What I know found out is, that it propably depends on whether the second seat finds its hardware. Maybe there are then some error entries in Xorg.0.log. which trigger that failsafe workaround.

      Comment


        #4
        Re: bulletproofX failsafeX and bad behavior

        oshunluvr runs dual Nvidia cards -- look for a post from him. I know that, in /etc/X11/xorg.conf, you need to specify the two different PCI bus IDs that you see when you list the PCI devices with
        Code:
        lspci

        Comment


          #5
          Re: bulletproofX failsafeX and bad behavior

          As I wrote, it works... I have both screens. Only if I remove one of the usb devices of the second screen (or eventually the second monitor), something triggers that failsafeX. The original (dual-seat) X-Server starts-up after I return to the console an leave that failsafeX...

          I want to disable that failsafe X. Simple remove that unnecessary feature.

          Comment


            #6
            Re: bulletproofX failsafeX and bad behavior

            Originally posted by boronk

            if I remove one of the usb devices of the second screen (or eventually the second monitor)
            USB devices on a screen, or monitor?

            Sorry, I don't know about such devices. Usually when you plug or unplug a USB device, it is expected that the "device notifier" will be triggered.

            On the console restarting, when X has failed to start automatically, KDM will continue to try to start until you issue
            Code:
            sudo service kdm stop

            Comment


              #7
              Re: bulletproofX failsafeX and bad behavior

              In a dual seat configuration, especially with 2 seperate graficadaptors, you have two graficcard, two monitors, two mice and two keyboards.

              The problem is that the default configuration means that you get either some type of xinerama or only one session on the first device/monitor combo.

              To exactly specify which mouse/keyboard belongs to which monitor you have to specify everything in the xorg.conf. The usb devices via /dev/input/by-id oder by-path, if you only take input/mouse1 /mouse2 these can change depending on startup of the system.

              If now, the xserver is started with only one of the seats attached (and therefore the devices are missing) there are errors in the /var/log/Xorg.0.log. Despite that it starts if configured the right way (what it does, I can see it)

              Now that failsafeX thingy fires up its own xserver and disturbes everything perhaps due to that entries in the errorlogs or other things I don't know

              In addition to that, I simply want, if X fails, a console like in the good old days. Nothing else. No crappy replacement X-Server which tells me that something is wrong. So the best would be to disable failsafeX.









              Comment


                #8
                Re: bulletproofX failsafeX and bad behavior

                have you tried removing /etc/init.d/failsafe-x ?

                or how about editing /etc/X11/xorg.conf.failsafe to some configuration more to your liking?

                Please Read Me

                Comment

                Working...
                X