Re: 2.6.0-test6 ruby success with matrox G550, and some questions

[Helge H. <hel...@ai...>]

Svetoslav Slavtchev wrote:

> 
> do they already include the XFree-PrefBusID patch ?
> (would be really nice addition in the howto)
> or do you use the video hack ?
> 
I use neither.  I believe these things are for multi-card
issues. (X server stupidly disabling other cards)
But I have only one card at this time, there are no
other cards there to disable via pci programming.

I use a BusID (not prefBusID) for the accelerated
server - it  is probably not necessary.  Just something I
added because I read about it, preparing for a future with
two cards.  Specifying the same BusID for fbdev goes wrong,
the server notices that it can't grab that card because
it is in use, and quits. 
Fortunately, the fbdev driver doesn't need to grab a card
at all, it merely grabs a framebuffer device and uses its
memory.  

>>>From /var/log/XFree86.1.log:
>>(II) LoadModule: "fbdev"
>>(II) Loading /usr/X11R6/lib/modules-dri-trunk/drivers/fbdev_drv.o
>>(II) Module fbdev: vendor="The XFree86 Project"
>>        compiled for 4.3.0, module version = 0.1.0
>>        ABI class: XFree86 Video Driver, version 0.6
>>
>>>From /etc/X11/XF86Config-4  (accelerated)
>>Section "Device"
>>        Identifier      "Matrox G550"
>>        Driver          "mga"
>>        BusID           "PCI:01:00:0"
> 
> 
>>        Option          "UseFBDev"              "true"
> 
> 
> using the matrox driver
> with this turned off i got X using 100% cpu and nothing on the screen
> with this turned on not sure, but the same or imediate lock up

Come to think of it, "UseFBDev" doesn't say anything
about _which_ fbdev to use.  So I guess it uses the first one.
That could cause all sorts of strange bugs if the first one
isn't the right one.

> 
> 
>>        Option          "HWcursor" "off"   #avoid cursor corruption
>>        Option          "AGPMode" "2"      #Faster 3D...
> 
> 
>>        Option          "DRIReinit"        #Possibly several servers with
>>DRI
> 
> never tried that
It shouldn't make a difference as long as DRI only is used on one display.
> 
> 
>>EndSection
>>
>>The last option because someone on the net got DRI working on two
>>matrox cards, (PCI+AGP) but only one at a time, unfortunately.

>>>two things here:
>>>1.) DRI doesn't support multiple cards
>>>(and it doesn't seems this to be on the TODO list
>>> of the DRI developers)
>>
>>Too bad.  Theoretically this should be _trivial_ for
>>dual-seat two-card setups, because the two xservers are
>>fully independent and so are the two graphichs cards.
>>I wonder what they are running up against.
>>
>>Of course the much more common case of one seat, several
>>cards aren't that easy - but I'm not trying for that.
> 
> 
> Hi Hi
> 
> Theoretically there are about 15-20 users(known to me) of such system,
> and i doubt that someone complained about the problem.
> 
Time to complain then. :-)
They'll probably just tell me to do it myself, perhaps I
can get enough information to try.

> there was a guy who wanted to get it running for some kind of commersial
> system/ project,
> i think he didn't needed multiple users, not sure about Xinerama, but
> on the dri-devel list he got advised to ask for commersial support
> from one of the developers's X releated company
> 
> IIRC the dri developer mentioned that no one thought of developing
> such thing, and generally the core itself shouldn't be changed much,
> but the X drivers needed major chages, and may be he could make it work with
> certain driver
> against a paiment

Hm.  X already works well in a dual seat setup, wonder what those major
changes are.  DRI already uses a device driver, using another driver
shouldn't be a problem.  I am tempted to get a pci card and use a
chroot so both X servers can get their own "/dev/dri/card0" which 
happens to be different devices.   The problem is time, and
which pci card to try.  I happen to like matrox for their good
picture quality (sharp and no flickering), and history of good dual
screen support.

>>>only choice is to use Nvidia cards with the closed source driver
I guess I could live with a closed-source X driver, if it
works.  But not a closed kernel driver, I run experimental
kernels and the module interfaces breaks all the time.
>>
>>Which is why I'll buy a card if I believe it'll work.  Accelerated
>>2D on both screens is nice too, of course.
>>
>>>(G200/450 MMS series could work as they have
>>>different BusID's, but are untested -- too expensive)
>>>
>>
>>Are these effectively two cards in a single slot then?
> 
> 
> i assume almost yes,

Any information about the "almost" part?  Are they sharing
something (such as 3D hw) that might prevent fully independent
use of the two heads?
The one thing I don't mind so much is shared clock/ramdac, I have two
identical screens so the ideal frequency and resolution is
the same for both.

> and i always wanted to get one of the 4 headed one's 
> they do have 2/4 G200/G450 chips with separate BusID's on them
>   
Wow - the strange things that exists...  
I have little use for more than 2 seats, but I see how a 4-way
solution could be great when there is that many people.
> 
>>
>>Well, 2.6.0-test6 (without ruby) works fine with
>>framebuffer console.  It dies only if I use ruby.
> 
> 
> which ruby-2.6 is this ?
It is ruby-260t6-20030930.diff.bz2 on top of plain 2.4.0-test6
A search for ruby-260t6 turns up:
ruby-260t6-20031015.diff.bz2      (This is the newer one?)
ruby-260t9-CVS-20031028.tar.bz2   (test9 ruby? exciting!)

> the one with real multi-user console, or the earlier
> with only multiuser X ?
> 
I don't know the differences between them, I don't usually
find much version-specific information.  I don't
think the 20031015 was available when I downloaded the patch.

> if it's the first one may be fbcon might get confused
> somehow by the 2 fb's on a single card, which might be
> not properly initialized without matroxset that early
> or might be Aivils did missed smth(but i doubt it)

I don't think matroxset makes a difference for _using_
the framebuffers, it only decides which one is visible
on what connector.  Framebuffer X (and accelerated)
works just fine "blind" if I mess up a matroxset command.

> can you try the earlier patch?
I suppose you mean the later one as I
seem to be using the earlier one?

That 260t9-CVS version seems even more interesting, unless
it is "work in progress" with known problems.  I'll
probably try that one first.

Helge Hafting