This would also resolves we're seing e.g. in Bug #352867 and Bug #210988.

And BusID related issues like Bug #327028.

I'm very much in favor of this. Given that multicard support in X.org in general is pretty unstable ATM, this sounds very reasonable.

*** Bug 400808 has been marked as a duplicate of this bug. ***

*** Bug 352867 has been marked as a duplicate of this bug. ***

*** Bug 327028 has been marked as a duplicate of this bug. ***

*** Bug 404812 has been marked as a duplicate of this bug. ***

*** Bug 404349 has been marked as a duplicate of this bug. ***

Are there any plans on re-enabling this feature or making a work around?  I never had any trouble with my current mutilcard setup with older versions of SuSE/openSUSE.  Not to mention the fact that they work fine in Windows too.  

In the mean time, it would be nice if you could at least make it display a warning that explains the situation and then setup one of the cards.  When I tried installing openSUSE 11.0 with an nVidia and ATI card it simply froze.

There are no plans to re-enable this feature once it's gone. 

You can be very lucky, if you never had any trouble with your current mutilcard setup with older versions of SuSE/openSUSE. 

One issue is that multicard setup isn't tested well, neither by us nor by upstream developers.

Next issue here is that more and more 2xGPU cards hit the market, which are detected as a Dualcard setup for SaX2. Appearently all OpenSource drivers fail completely when trying to drive them as Dualcard setup as you can see in the duplicates of this bugreport.

So before re-enabling this feature a huge number of drivers *and* driver combinations would be required to be fixed.

I don't see this will ever happen with the available ressources at SuSE/Novell
and X.Org upstream.

> In the mean time, it would be nice if you could at least make it display a
> warning that explains the situation and then setup one of the cards. When I
> tried installing openSUSE 11.0 with an nVidia and ATI card it simply froze.

If this would be so easy, I would have done it already. Your proposal is even
more than I plan to do.

*** Bug 402591 has been marked as a duplicate of this bug. ***

*** Bug 407946 has been marked as a duplicate of this bug. ***

Easiest way to implement this is to set CHIP="-c <x>" in startup/sax.sh as default (instead of CHIP=""). <x> is the primary card in SaX2 notation. 

An external tool can be used to figure out the primary card using PCI config space.

  "Luc told me how to figure out the primary gfx card. It's marked in 
  the PCI config space. You can see it in a "lspci -v -v" output. Check  
  for "Control I/O+" instead of "Control I/O-" for the VGA compatible
  devices."

Might be possible to write it in C with the help of libpci (or quick&dirty with bash). This external tool should live in tools/<newdir> (--> sax2-tools package).

Later we might integrate it in sysp (C++/stl).

How figure out SaX2 ChipID for primary device.

Option 1:
---------
sax2 -p --> sysp -c:

Output is result of for-loop over PCI structures (sysp/server.c, Showcards() in sysp/sysp.c, there's also a copy of pci.c in SaX2). Do the same to figure out the right SaX2 ChipID for the primary device. Add an option to sysp, so sysp gives you the SaX2 ChipID for a given device. Or even better enhance sysp with an option so it shows you only the primary device.

Option 2:
---------
'sysp -c' | grep "bus:slot:function" | awk '{print $2}'

Ok. I took the quick & dirty route (Option 2).

-------------------------------------------------------------------
Wed Jul 16 11:30:59 CEST 2008 - sndirsch@suse.de

- disable intelmagic by default; obsoleted by single card setup,
  which we use as default now

-------------------------------------------------------------------
Wed Jul 16 10:29:40 CEST 2008 - sndirsch@suse.de

- no longer set BusID for single card configurations (bnc #381644)

-------------------------------------------------------------------
Tue Jul 15 17:37:02 CEST 2008 - sndirsch@suse.de

- configure only primary VGA card by default, i.e. no multicard
  setups any more by default; you can still force SaX2 to create
  a mulitcard setup with "-c 0,1" (bnc #381644)

Fixed for Factory (upcoming openSUSE 11.1/SLE11) and buildservice (project SaX2).

*** Bug 407795 has been marked as a duplicate of this bug. ***

*** Bug 412779 has been marked as a duplicate of this bug. ***

*** Bug 412520 has been marked as a duplicate of this bug. ***

*** Bug 417882 has been marked as a duplicate of this bug. ***

Hmm. For some reasons during a regular installation of openSUSE 11.1 Alpha2 the X configuration still crashes with a multicard setup (tested with a NVIDIA DualGPU card), you're getting a silly proposal of 800x600@16bpp and end up
with the xorg.conf of installation (fbdev driver based). I'm afraid I need to
reopen this one. Marcus/Jens-Daniel, what's exactly done by yast2-x11 to create
the xorg.conf at hardware configuration stage?

Wrong, you even end up with a broken xorg.conf (X only started because I mistakenly booted in failsafe mode, where xorg.conf.install is used).

Marcus? See my comment #21.

Just to make sure. Using sax2 for configuration works fine.

Just talked to Marcus. Any magic in sax.sh needs to be provided also in  libsax/init.cpp (yast creates an object called SaXInit, SaXInit calls only
init.pl without any magic of sax.sh).

Created attachment 237454 [details]
no-multicard-by-default.diff

sax.sh magic, which needs to be provided by libsax/init.cpp as well.

*** Bug 417575 has been marked as a duplicate of this bug. ***

I've added the required changes by Marcus now. What's missing is the code in XLib.pm:loadApplication (yast2-x11):

  $sinit -> setPrimaryChip();

Reassigning to Jens Daniel. Please reassign back when you've added it, so I can give it a try. Thanks.

This way?

--- XLib.pm.orig        2008-09-04 16:24:09.000000000 +0200
+++ XLib.pm     2008-09-04 16:24:33.000000000 +0200
@@ -62,6 +62,7 @@ sub loadApplication {
        my $sinit = new SaX::SaXInit;
        $ENV{HW_UPDATE} = 1;
        $sinit -> doInit();
+       $sinit -> setPrimaryChip();
        my @importID = (
                $SaX::SAX_CARD,
                $SaX::SAX_DESKTOP,

Thanks a lot for the patch.
Fixed in yast2-x11 for Code11. Please give it a try.

Unfortunately this didn't help. After updating yast2-x11 and all sax2 packages the X11 configuration still crashes the same way and creates a broken xorg.conf. --> e154

I've tested by touching /var/lib/YaST2/runme_at_boot and rebooting. Don't know
how to debug this. :-(

machine hostname has changed to g167.

sorry I think I gave the wrong information. The function 

   $sinit -> setPrimaryChip();

must be called _before_ 

    $sinit -> doInit();

is called. The function creates an option to the program called
by doInit() so setting the option after doInit() is called has
no effect

Looks like this doesn't work either. :-(

y2start.log:
[...]
       |-- YaST procedure ended successfully
       |-- Reset memory allocation: overcommit_memory=0
       |-- Creating hook script list: postSecondCall...
Stage [2]: Starting S09-cleanup...
Stage [2]: =======================
       |-- kill X-Server with PID: 3583
       |-- Shutdown SSH daemon and network interfaces...
       |-- Stopping UTF-8 mode...
       |-- Creating hook script list: postSecondStage...

Created attachment 238250 [details]
y2log

Relevant lines in y2log.

Created attachment 238252 [details]
y2log

Marcus, J. Daniel, how to continue here? Machine is again e154.

Is it possible to start the YaST2 hardware proposal on a running system instead of touching /var/lib/YaST2/runme_at_boot and reboot the system?

Created attachment 238601 [details]
XLib.pm.diff

Enables test code in XLib.pm (run with "perl XLib.rpm") and replaces function calls, which segfaults, with dummy values. Looks like

- is3DCard()
- getCardVendor()
- getCardModel()

no longer work. :-(

Machine is g167.

Not sure why, but now the unchanged XLib.pm testcode no longer segfaults. Machine has changed back to e154.

And now it crashes again. Even when removing the line 

  $sinit -> setPrimaryChip();

in loadApplication().

(In reply to comment #43 from Stefan Dirsch)
> Not sure why, but now the unchanged XLib.pm testcode no longer segfaults.
> Machine has changed back to e154.

I've been stupid. I tested with the intel onboard graphics configuration instead of Dual-GPU NVIDIA card.

I'm getting more and more confused. I think I should test again with an installation, which already contains all required changes in SaX2 and yast2-x11, i.e. not before Beta1. Until this I keep this bugreport open.

(In reply to comment #34 from Marcus Schaefer)
> sorry I think I gave the wrong information. The function 
> 
>    $sinit -> setPrimaryChip();
> 
> must be called _before_ 
> 
>     $sinit -> doInit();
> 
> is called. The function creates an option to the program called
> by doInit() so setting the option after doInit() is called has
> no effect

This is still broken in current yast2-x11 in STABLE. Jens-Daniel, please fix this. Otherwise testing with Beta1 won't help either. :-(

Fixed and submitted.
Please test, thanks.

Doesn't look good with build40 (pre-Beta1). :-( Required changes in yast2-x11 needed to be reverted for Beta1. See Bug #427371 for more details.

Bug #427371 finally fixed.

*** Bug 433851 has been marked as a duplicate of this bug. ***

*** Bug 441182 has been marked as a duplicate of this bug. ***