Re: matroxfb, anybody? (More details...)

Re: matroxfb, anybody? (More details...)

[dhiltgen@toocool.calpoly.edu]

I apologize for the length, but I don't want to leave anything
out that might be critical....

Let me open with two quick questions.  A while back on linux-kernel
someone said that they had ported X_SVGA with Matrox acceleration
to FB, and Geert asked the guy for a copy of the patch.

What are the odds that I could get a hold of that, and that it would
compile and possibly run under PPC?  Slim to none I bet, but 
it would be nice...

And the second, I have managed to get X working on both displays at once,
but the first X server freezes until I exit the second.  I used "X :1"
for the second.  Is there some other trick to keep the first one alive?
...Mouse stops, and I tried firing up "xterm -display :0.0 &" and they
didn't appear until after I exited the :0.1 X server, at which point all
of the xterms I had started popped up on the :0.0 server and the mouse
woke back up. 

...ok, on to the nitty gritty details...

On Sat, Jan 30, 1999 at 02:32:32PM -0100, Owen Waller wrote:
> 
> Hi,
> 
> > I'm running an x86 Matrox card in my 8600, and it "sort of" works
> > right now on 2.2.0.  It appears that there are definitely some kernel
> 
> To be honest I haven't tried this. I've been snowed under with work since
> October :-(. The last thing I tried was building a 2.2pre6 kernel which
> worked o.k. bar breaking my PPP connection. I didn't build the kernel
> with matroxfb support though as I thought the less I experiment with the
> better.

I've used both 2.2 pre 7 and I'm now playing with 2.2.1.

> > bugs as far as mode switching, as sometimes control and matrox end up
> > duplicating each other resulting in very funky displays.  I had to hack
> 
> This doesn't sound good. What exactly are you doing to achieve this?

Initially I was "moving" /dev/fb[01] back and forth so that I could try
to get X working.  Now I'm using ${FRAMEBUFFER} so that I don't have to
do that.  ...the symptoms described below appear for both.

OK, scenario goes like this.

/dev/fb0 = control  -- on bootup, this is the console
/dev/fb1 = x86 Matrox Mil. I -- on bootup, displays garbage from last session.
           does not turn on until kernel probes (aka, OF doesn't turn it on)
           I have turned on the #define in matroxfb.c for debugging.

	uname -a
Linux hysteria.insanity.org 2.2.1 #3 Sat Jan 30 12:20:05 PST 1999 ppc unknown

	ls -l /dev/fb* 
crw-r--r--   1 root     root      29,   0 Jan  4 05:53 /dev/fb0
crw-r--r--   1 root     root      29,  32 Jan 21 07:42 /dev/fb1


If I setenv FRAMEBUFFER /dev/fb0 (not really needed, but to be explicit)
and "startx" I get an X session on controlfb, as expected.  Everything
looks fine and dandy.  

So, if I "fbset -i" back on console, then I get the controlfb information
as expected, but if I "fbset -i -fb /dev/fb1" the console immediately
switches to /dev/fb1, but the fonts are all messed up (I'm guessing the
timing values for fb0 are somehow getting used)  I can't see what I type,
but the output is definitely trying to go to the matrox.  The funny part
is the "scroll" is controlled by the kernel, which still correctly scrolls
/dev/fb0 (control) so whenever I type enough to get a scroll to occur,
matrox doesn't, but control does (even though no new text has appeared
on control.)

At this point I had a vyres set to something huge, so I did an
"fbset -vyres 768" and poof, console went back to control.

I then ran "fbset -i -fb /dev/fb1" and console switched back to matrox
with messed up fonts.  At some point I did a setenv FRAMEBUFFER /dev/fb1
and ran "startx" and it came up on the matrox.  The only problem is that
the color pallet is all jacked up.  Again, I'm guessing that somehow
it's using controlfb information incorrectly for the matroxfb.

It appears that the issue is that somehow the kernel is using fb0
sometimes, and others it's using FRAMEBUFFER, or the "-fb" argument.
When I try to change settings using fbset it's like both frame buffers
get set at once, and one of them gets confused since the timings are only
valid for one of the cards.  ...or, the FB code in the kernel _really_
isn't very clean when it comes to multiple heads right now, and some
code just assumes /dev/fb0 is console and uses it without checking for
the proper state information.  I guess the whole thing is complicated 
by the fact that sometimes it's user space stuff, other times it's kernel 
space stuff messing with the fb.

> > the kernel slightly, in that it assumes if you have a Mac, well then you
> > must have a Mac matrox card, and OF should take care of initialization.
> > Nope, I've got a x86 card, and it has to be initialized by the kernel.
> > Simple one line hack in the init function for matroxfb.  
> 
> o.k. as far as I know Petr set things up so that under a Mac the card was
> always initialised by OF - even for x86 cards (like my mystique and your
> mil. I). The change is listed in Petr's readme/changes file. Petr can you
> comment on this?

I don't think so.

in drivers/video/matroxfb.c:

#ifndef MODULE
__initfunc(void matroxfb_init(void))
{
        DBG("matroxfb_init")
#if defined(CONFIG_FB_OF)
/* Nothing to do, must be called from offb */
#else
        matrox_init();
#endif
}

matrox_init never gets called on my system, so the card never inits.
I just commented out the #ifdef stuff so that matrox_init always gets
called and the card magically appears.


> What I'll do is bring my kernel sources up to 2.2.0-final and try setting
> up my Mystique again. Then let you know what happens.

I'm definitely interested....  Unfortunately I doubt I can use any of
your timing information, but who knows...

> On a realted note though, has anybody got a matrox card running under
> pre-R5 with the XFree86, framebuffer stuff running? I'm still running R4
> but once R5 is out I'll move over to XFree from XPmac.

Well, I'm running R4, but I have XF68_FBDev-ppc-19980910 from Geert's page, 
and when I run it on the matrox card I get:

XFree86 Version 3.3.2 / X Window System
(protocol Version 11, revision 0, vendor release 6300)
Release Date: March 2 1998
        If the server is older than 6-12 months, or if your card is newer
        than the above date, look for a newer version before reporting
        problems.  (see http://www.XFree86.Org/FAQ)
Operating System: Linux 2.1.120 ppc [ELF] 
Configured drivers:
   FBDev: Server for frame buffer device
   (Patchlevel 9): mfb, afb, cfb8, cfb16, cfb24, cfb32
(using VT number 7)

XF86Config: /etc/XF86Config
(**) stands for supplied, (--) stands for probed/default values
(**) XKB: disabled
(**) Mouse: type: busmouse, device: /dev/adbmouse, buttons: 3
(**) FBDev: Graphics device ID: "Linux Frame Buffer Device"
(**) FBDev: Monitor ID: "Generic"
(**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Ty
pe1/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6
/lib/X11/fonts/100dpi/"
(**) FBDev: Using default frame buffer video mode
(--) FBDev: Frame buffer device: MATROX
(--) FBDev: Video memory: 4096K @ 0x81000000
(--) FBDev: MMIO regs: 16K @ 0x80804000
(--) FBDev: Type 0 type_aux 0 bits_per_pixel 8
(--) FBDev: Unknown hardware accelerator type 16
(--) FBDev: No hardware acceleration used
(--) FBDev: Enabled virtual desktop
(--) FBDev: Using cfb8 driver


The current mode that I'm using, that "sort of works" for matroxfb is:
(I'd _really_ like to be able to change this, but without timing values
I can't get it to work, and as I said in the previous e-mail appending
to the kernel video=matrox:vesa:<hex-code> results in a immediate panic
(no error message, it just freezes) Any ideas short of getting the values
from someone with a Mac version of the card who can use vmode or whatever
to set the mode properly?)

fbset -i -fb /dev/fb1

mode "name"
    # D: 79.554 MHz, H: 59.905 kHz, V: 74.509 Hz
    geometry 1024 768 1024 768 8
    timings 12570 164 44 30 3 96 3
    hsync high
    vsync high
endmode

Frame buffer device information:
    Name        : `MATROX'
    Address     : 0x81000000
    Size        : 4194304
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 8
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 1024
    MMIO Address: 0x80804000
    MMIO Size   : 16384
    Accelerator : Matrox MGA2064W (Millennium)


Thanks for any and all input!   I'll be more than happy to help get this 
working via kernel hacking... just tell me where to start.  :)

I'm honestly less concerned with the console jumping back and forth.
I just want to be able to fire up X on both monitors at the maximum
res/depth for each card.

-- 
Daniel Kerry Hiltgen     Computer Science     Cal Poly, San Luis Obispo, CA  
dhiltgen@www.itslab.calpoly.edu    http://www.itslab.calpoly.edu/~dhiltgen/

"In a world without fences who needs Gates?"  1997 JavaOne Conference

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Gerd Knorr]

In lists.linuxppc.dev you write:

>I apologize for the length, but I don't want to leave anything
>out that might be critical....

>Let me open with two quick questions.  A while back on linux-kernel
>someone said that they had ported X_SVGA with Matrox acceleration
>to FB, and Geert asked the guy for a copy of the patch.

Thats me.  The patch is available from
	http://www.in-berlin.de/User/kraxel/xfree86/

>What are the odds that I could get a hold of that, and that it would
>compile and possibly run under PPC?  Slim to none I bet, but 
>it would be nice...

As far I know, Geert got it to compile on ppc, but it's not working yet.

  Gerd

-- 
We are ftpadm of FB13. Prepare to be mirrored. Resistance is futile.
	-- ftp.cs.tu-berlin.de greeting message

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Geert Uytterhoeven]

On Sun, 31 Jan 1999, Gerd Knorr wrote:
> In lists.linuxppc.dev you write:
> 
> >I apologize for the length, but I don't want to leave anything
> >out that might be critical....
> 
> >Let me open with two quick questions.  A while back on linux-kernel
> >someone said that they had ported X_SVGA with Matrox acceleration
> >to FB, and Geert asked the guy for a copy of the patch.
> 
> Thats me.  The patch is available from
> 	http://www.in-berlin.de/User/kraxel/xfree86/
> 
> >What are the odds that I could get a hold of that, and that it would
> >compile and possibly run under PPC?  Slim to none I bet, but 
> >it would be nice...
> 
> As far I know, Geert got it to compile on ppc, but it's not working yet.

It crashes with a bus error. That is, the unaccelerated version. I don't have a
Matrox, and I had to disable the ATI code because it contains inline ia32
assembler.

I think the bus error is related to trying to map the frame buffer using
/dev/mem instead of /dev/fb0. I know that shouldn't give a bus error, but I saw
a similar thing with my (still experimental) program to get some useful video
out of my S3 Vision968. Last time I tried, it crashed with a bus error when
writing to the VRAM. Unfortunately I can't be 100% sure yet that it's a bug in
recent kernels, since I had to recompile that test program after I migrated to
Debian, which uses glibc-2.1pre.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Geert Uytterhoeven]

On Sat, 30 Jan 1999, dhiltgen@toocool.calpoly.edu wrote:
> It appears that the issue is that somehow the kernel is using fb0
> sometimes, and others it's using FRAMEBUFFER, or the "-fb" argument.
> When I try to change settings using fbset it's like both frame buffers
> get set at once, and one of them gets confused since the timings are only
> valid for one of the cards.  ...or, the FB code in the kernel _really_
> isn't very clean when it comes to multiple heads right now, and some
> code just assumes /dev/fb0 is console and uses it without checking for
> the proper state information.  I guess the whole thing is complicated 
> by the fact that sometimes it's user space stuff, other times it's kernel 
> space stuff messing with the fb.

There are known problems with multiheadness. Unfortunately I can't `see' what's
wrong until I get my second video board working. Yes, I'm embarassed by that.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Geert Uytterhoeven]

On Mon, 1 Feb 1999, Petr Vandrovec Ing. VTEI wrote:
> Strange. I tried two fbdev servers (on i386) and they both works. There is
> only one problem I know of: only one, foreground, server updates screen.
> I think that fbdev server thinks that he is not visible when it gets

The console subsystem isn't yet multi-head aware. The X server shouldn't
receive the console switch signal when you switch to another VC on a different
frame buffer device. But to make that work and make really use of that, we need
support for multiple input devices first.

> console switch signal... SVGA server even switches into textmode... But
> they work in paralell. Also, maybe that you should run X on fb1 using

Yes, XF86_SVGA switches to text mode on VC switch. BTW, have you tried
XF86_SVGA with Gerd Knorr's patches to make it use fbdev? I assume that one
will keep the display image on VC switch.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Petr Vandrovec Ing. VTEI]

Hello Owen, hello D?, hello anybody,
> What are the odds that I could get a hold of that, and that it would
> compile and possibly run under PPC?  Slim to none I bet, but
> it would be nice...
  it should work as long as XFree does not do byteswapping because of
Matrox is switched into big endian mode with matroxfb. Unfortunately,
I did not test it yet because of my PowerStack refuses to boot with
Gabriel's PrepLoader, so I have something important to work out. Sorry.
> And the second, I have managed to get X working on both displays at once,
> but the first X server freezes until I exit the second.  I used "X :1"
> for the second.  Is there some other trick to keep the first one alive?
> ...Mouse stops, and I tried firing up "xterm -display :0.0 &" and they
> didn't appear until after I exited the :0.1 X server, at which point all
> of the xterms I had started popped up on the :0.0 server and the mouse
> woke back up.
Strange. I tried two fbdev servers (on i386) and they both works. There is
only one problem I know of: only one, foreground, server updates screen.
I think that fbdev server thinks that he is not visible when it gets
console switch signal... SVGA server even switches into textmode... But
they work in paralell. Also, maybe that you should run X on fb1 using
con2fb /dev/fb1 /dev/tty#X
<switch to tty#X>
FRAMEBUFFER=/dev/fb1 X vt#X
(I'm doing it this way)
> I've used both 2.2 pre 7 and I'm now playing with 2.2.1.
> /dev/fb0 = control  -- on bootup, this is the console
> /dev/fb1 = x86 Matrox Mil. I -- on bootup, displays garbage from last session.
OK.
> So, if I "fbset -i" back on console, then I get the controlfb information
> as expected, but if I "fbset -i -fb /dev/fb1" the console immediately
> switches to /dev/fb1, but the fonts are all messed up (I'm guessing the
Cannot comment on this because of my kernel (with my patches) says

# fbset -i -fb /dev/fb1
ioctl_FBIOGET_VSCREENINFO: Invalid cross-device link

That means that fbset tried to work with console belonging to /dev/fb0
through /dev/fb1 device. And it is bug in kernel that it is allowed
and it ends up with calling matroxfb_set_var() with console owned by /dev/fb0
without calling FBIOPUT_CON2FBMAP. What happens is unknown, undefined and
I think that you are lucky that it did not died :-( (patch to do this
is available at ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/fbaddon.gz,
but it is for something like 2.2.0-pre1 and will be never included into
Linus kernel as is.)
> timing values for fb0 are somehow getting used)  I can't see what I type,
> but the output is definitely trying to go to the matrox.  The funny part
Yes, it could happen.
> is the "scroll" is controlled by the kernel, which still correctly scrolls
> /dev/fb0 (control) so whenever I type enough to get a scroll to occur,
> matrox doesn't, but control does (even though no new text has appeared
> on control.)
Yes. You should switch current (or some tty) to /dev/fb1 and then
invoke fbset -fb /dev/fb1 from that tty. con2fb is on Geert's home page.
> I then ran "fbset -i -fb /dev/fb1" and console switched back to matrox
> with messed up fonts.  At some point I did a setenv FRAMEBUFFER /dev/fb1
> and ran "startx" and it came up on the matrox.  The only problem is that
You should not do it with fbset -i -fb /dev/fb1. You should use con2fb,
fbset -i -fb /dev/fb1 from tty device on fb0 corrupts internal kernel
structures.
> > > the kernel slightly, in that it assumes if you have a Mac, well then you
> > > must have a Mac matrox card, and OF should take care of initialization.
> > > Nope, I've got a x86 card, and it has to be initialized by the kernel.
> > > Simple one line hack in the init function for matroxfb.
If you have Matrox which cannot be initialized by OF, you should not
enable CONFIG_FB_OF. If you have both devices, you can try to persuade
OF to have two devices or edit sources. Sorry.
> in drivers/video/matroxfb.c:
>
> #ifndef MODULE
> __initfunc(void matroxfb_init(void))
> {
>         DBG("matroxfb_init")
> #if defined(CONFIG_FB_OF)
> /* Nothing to do, must be called from offb */
> #else
>         matrox_init();
> #endif
> }
>
> matrox_init never gets called on my system, so the card never inits.
> I just commented out the #ifdef stuff so that matrox_init always gets
> called and the card magically appears.
Yes, you must add "MTRX,...." somewhere into your OF configuration
(my PReP does not have OF and I never saw it...) If you uncommented #define
above, be sure that you commented out complement part from
drivers/video/offb.c - otherwise matroxfb can be initialized twice, thus
you'll get two fb's per one hardware :-(
> The current mode that I'm using, that "sort of works" for matroxfb is:
> (I'd _really_ like to be able to change this, but without timing values
> I can't get it to work, and as I said in the previous e-mail appending
> to the kernel video=matrox:vesa:<hex-code> results in a immediate panic
> (no error message, it just freezes) Any ideas short of getting the values
> from someone with a Mac version of the card who can use vmode or whatever
> to set the mode properly?)
Could you try put console to serial port and send me panic message, if
any comes out through serial port?
> I'm honestly less concerned with the console jumping back and forth.
> I just want to be able to fire up X on both monitors at the maximum
> res/depth for each card.
con2fb is your friend...
                                    Best regards,
                                            Petr Vandrovec
                                            vandrove@vc.cvut.cz

P.S.: I'm not on the linuxppc-dev list, so CC me if you think that
I'm interested in that message.

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Geert Uytterhoeven]

On Mon, 1 Feb 1999, Petr Vandrovec Ing. VTEI wrote:
> On  1 Feb 99 at 11:35, Owen Waller wrote:
> > > (my PReP does not have OF and I never saw it...) If you uncommented #define
> > > above, be sure that you commented out complement part from
> > > drivers/video/offb.c - otherwise matroxfb can be initialized twice, thus
> > > you'll get two fb's per one hardware :-(
> > Is there any way that this could be changed? I don't need my internal
> > video (control) to work, but I'd rather have it and the matrox compiled
> > into the one kernel without a hack. Unless Geert you know some way of
> > "fudging" an non-OF card into the OF device tree? OR Petr could you
> > possibly work in a #define construct so that Daniel's "hack" became
> > official? (mind you neither of these are very general solutions).
> There is a problem. What if you HAVE matrox in OF ? Of course,

Yes, Mac Matrox boards appear in the OF tree.

> I remove this #ifdef from driver and add some variable to ensure, that
> driver will be initialized only once... And if matroxfb is not your primary
> head, you can, as temporary solution, compile it as module. It should
> work without problems then.

This is indeed a problem. We should use something like request_region() to
claim the space used by the board. That way we can make sure each board is
initialized only once. Boards that are left uninitialized and that appear in
the OF tree should be handled by offb as a last resort.

> > Also does anybody know how this situation changes if you use BootX to boot
> > (I don't so I can't comment on this). Would BootX map the mystique from
> As I do not have anything with OF around here, tell me what you want
> and I'll do it...

Since BootX creates a fake OF device tree, I suspect it to appear in the tree.
Can you use your Mystique under MacOS? This is of course a prerequisite for
BootX seeing your board.

> P.P.S.: Should not I remove whole #ifdef CONFIG_FB_OF from driver?
> Is there anybody who uses this additional feature?

If you remove it, Matrox boards will be initialized by both matroxfb and offb
(unless you disable offb completely, but then other boards like control are no
longer found), which is not what we want.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Owen Waller]

Hi Petr, Daniel and everyone else.

o.k. well after a weekend updating my kernel sources to 2.2.1 here's what
I get...

> > And the second, I have managed to get X working on both displays at
> > but the first X server freezes until I exit the second.  I used "X :1"
> > for the second.  Is there some other trick to keep the first one alive?
> > ...Mouse stops, and I tried firing up "xterm -display :0.0 &" and they
> > didn't appear until after I exited the :0.1 X server, at which point all
> > of the xterms I had started popped up on the :0.0 server and the mouse
> > woke back up.
> Strange. I tried two fbdev servers (on i386) and they both works. There is
> only one problem I know of: only one, foreground, server updates screen.
> I think that fbdev server thinks that he is not visible when it gets
> console switch signal... SVGA server even switches into textmode... But
> they work in paralell. Also, maybe that you should run X on fb1 using
> con2fb /dev/fb1 /dev/tty#X
> <switch to tty#X>
> FRAMEBUFFER=/dev/fb1 X vt#X
> (I'm doing it this way)

Daniel, I haven't tried this yet on my Mystique. If Petr's suggestions
still doesn't work let me know nad I'll try testing this on my machine.
The last time I tried con2fb (a few months ago) it worked fine for moving
the console about, but I didn't try X.

> > So, if I "fbset -i" back on console, then I get the controlfb information
> > as expected, but if I "fbset -i -fb /dev/fb1" the console immediately
> > switches to /dev/fb1, but the fonts are all messed up (I'm guessing the

as far as I can tell fbset -i reports the correct information for fb0 -
matrox and fb1 - control. But I'll double check this when I get back
tonight.

> > > > the kernel slightly, in that it assumes if you have a Mac, well then you
> > > > must have a Mac matrox card, and OF should take care of initialization.
> > > > Nope, I've got a x86 card, and it has to be initialized by the kernel.
> > > > Simple one line hack in the init function for matroxfb.
> If you have Matrox which cannot be initialized by OF, you should not
> enable CONFIG_FB_OF. If you have both devices, you can try to persuade
> OF to have two devices or edit sources. Sorry.
> > in drivers/video/matroxfb.c:
> >
> > #ifndef MODULE
> > __initfunc(void matroxfb_init(void))
> > {
> >         DBG("matroxfb_init")
> > #if defined(CONFIG_FB_OF)
> > /* Nothing to do, must be called from offb */
> > #else
> >         matrox_init();
> > #endif
> > }

Daniel, well after some poking around in the kernel source I'll agree with
you on this ;-). When I first got 2.2.1 compiled it didn't even see the
Mystique. Once I took your hack though things seem to be o.k.

> > matrox_init never gets called on my system, so the card never inits.
> > I just commented out the #ifdef stuff so that matrox_init always gets
> > called and the card magically appears.
> Yes, you must add "MTRX,...." somewhere into your OF configuration
> (my PReP does not have OF and I never saw it...) If you uncommented #define
> above, be sure that you commented out complement part from
> drivers/video/offb.c - otherwise matroxfb can be initialized twice, thus
> you'll get two fb's per one hardware :-(

Is there any way that this could be changed? I don't need my internal
video (control) to work, but I'd rather have it and the matrox compiled
into the one kernel without a hack. Unless Geert you know some way of
"fudging" an non-OF card into the OF device tree? OR Petr could you
possibly work in a #define construct so that Daniel's "hack" became
official? (mind you neither of these are very general solutions).

As for editing drivers/video/offb.c - I don't think this is important. In
my case the card never shows up in the device-tree, cat'ing
/proc/device-tree doesn't show the card. It only appears on the PCI bus,
cat'ing /proc/pci does show the card. So if the card isn't in the device
tree then the matrox clause of offb.c is never called. Correct?

Also does anybody know how this situation changes if you use BootX to boot
(I don't so I can't comment on this). Would BootX map the mystique from
the PCI space into the OF device tree??

> > The current mode that I'm using, that "sort of works" for matroxfb is:
> > (I'd _really_ like to be able to change this, but without timing values
> > I can't get it to work, and as I said in the previous e-mail appending
> > to the kernel video=matrox:vesa:<hex-code> results in a immediate panic

I'm currently running with:

video=matrox:vesa:0x105 (or 0x118), and things have been rock solid.

Daniel how are you booting via, bootX or direct from OF?

> P.S.: I'm not on the linuxppc-dev list, so CC me if you think that
> I'm interested in that message.

consider it done :-)

Cheers


-------------------------------------------------------------------------
Owen Waller                     |   "...sometimes I think I'm a little
PhD. Student in Control Eng.    |    more English than I am French..."
Queens University               |              - Alain Prost 
Belfast                         |
Tele: +44 (0)1232 274085        |    Fax: +44 (0)1232 667023


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Petr Vandrovec Ing. VTEI]

On  1 Feb 99 at 11:35, Owen Waller wrote:
> > (my PReP does not have OF and I never saw it...) If you uncommented #define
> > above, be sure that you commented out complement part from
> > drivers/video/offb.c - otherwise matroxfb can be initialized twice, thus
> > you'll get two fb's per one hardware :-(
> Is there any way that this could be changed? I don't need my internal
> video (control) to work, but I'd rather have it and the matrox compiled
> into the one kernel without a hack. Unless Geert you know some way of
> "fudging" an non-OF card into the OF device tree? OR Petr could you
> possibly work in a #define construct so that Daniel's "hack" became
> official? (mind you neither of these are very general solutions).
There is a problem. What if you HAVE matrox in OF ? Of course,
I remove this #ifdef from driver and add some variable to ensure, that
driver will be initialized only once... And if matroxfb is not your primary
head, you can, as temporary solution, compile it as module. It should
work without problems then.
> Also does anybody know how this situation changes if you use BootX to boot
> (I don't so I can't comment on this). Would BootX map the mystique from
As I do not have anything with OF around here, tell me what you want
and I'll do it...
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz

P.S.: I'm not on the list, so please CC me...
P.P.S.: Should not I remove whole #ifdef CONFIG_FB_OF from driver?
Is there anybody who uses this additional feature?

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Benjamin Herrenschmidt]

On Mon, Feb 1, 1999, Geert Uytterhoeven
<Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:

>Since BootX creates a fake OF device tree, I suspect it to appear in the
tree.
>Can you use your Mystique under MacOS? This is of course a prerequisite for
>BootX seeing your board.

OF in the machine's ROM (not the card's ROM) should make _any_ PCI board
visible provided that it contains correct config-space registers with a
vendorID and a deviceID, which is required for all PCI cards anyway. The
board itself can optionally contain OF code which can then change things
in the device-tree but you will (should) always at least have a device
tree entry, even if you have no OF code on the board.

BootX will make the fake OF tree from MacOS Name Registry, which is
itself a translated version of OF tree (plus or minus a couple of things
since MacOS drivers can change it).

However, I've read somewhere that there is actually a difference between
Matrox boards with and without OF code: the OF code will set the board to
use big-endian pixels. It may also change a couple of other things, so
you can not rely on the state of the board at driver initialisation. You
will probably also have differences with or without Gabriel PReP
bootloader since it will be able to run any x86 bios code that lives here.


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Geert Uytterhoeven]

On Mon, 1 Feb 1999, Owen Waller wrote:
> > > There is a problem. What if you HAVE matrox in OF ? Of course,
> > Yes, Mac Matrox boards appear in the OF tree.
> 
> o.k. well the x86 board definelty doesn't... So we now have a more general
> problem:
> 
> If I have two idential video boards in my Mac one "mac" specific which
> shows up in the OF tree, and one that is x86 sourced and doesn't show up
> under OF how can we initialise both boards correctly.

That's indeed a case the problem will show up.

> > > I remove this #ifdef from driver and add some variable to ensure, that
> > > driver will be initialized only once... And if matroxfb is not your primary
> 
> im my case matroxfb will become my primary head, but I'd still like access
> to the internal (control) video in case soemthing in a new kernel dies
> before matroxfb is initialised.

So you need both offb+controlfb and matroxfb in your kernel.

> > > head, you can, as temporary solution, compile it as module. It should
> > > work without problems then.
> > This is indeed a problem. We should use something like request_region() to
> > claim the space used by the board. That way we can make sure each board is
> > initialized only once. Boards that are left uninitialized and that appear in
> > the OF tree should be handled by offb as a last resort.
> 
> Geert, I'm not sure what you are saying here. So you mean that an non-OF
> board whould "somehow" be initialised by another driver, and then the OF
> tree checked for uninitialised devices? Which in this case would
> presumably be the other "mac" specific video board. 

Suppose you have three boards:

  1. controlfb (in OF tree)
  2. Mac Matrox (in OF tree)
  3. normal Matrox (not in OF tree)

Offb will walk the OF tree and call the controlfb init routine for board 1 and
the matroxfb init routine for board 2. Board 3 will not be initialized. Hence
you have two frame buffer devices: fb0 and fb1.

Now suppose you modify matroxfb to not use OF probing, but PCI probing. You
also have to remove the test for `MTRX' in offb.c. Result: Offb will walk the
OF tree and call the controlfb init routine for board 1. It will see board 2 in
the OF tree and consider it as an `unknown' OF-capable board. So you have 2
frame buffer devices fb0 and fb1. Furthermore the PCI probing in matroxfb will
see both boards 2 and 3, and you end up with 2 more buffer devices fb2 and fb3.
But fb1 and fb1 are the same board!

A possible solution would be to ignore OF-capable boards (`MTRX') if matroxfb
is configured, and to always use PCI probing in matroxfb. The same is true for
ATI boards (atyfb can do PCI probing as well).

However, the best fix (IMHO) would be:

  1. Use a request_region() alike function to claim the frame buffer address
     region. This would make sure no more than one driver can claim the frame
     buffer of each board.
  2. Always use PCI probing in the chip specific drivers.
  3. Initialize offb only after all chip specific drivers, so offb is used as a
     fallback in case no other driver has claimed the board before.

Whether e.g. controlfb and the other Mac specific chipsets should use PCI
probing or be called by offb (as is currently done) is left out of the
discussion.

> > > P.P.S.: Should not I remove whole #ifdef CONFIG_FB_OF from driver?
> > > Is there anybody who uses this additional feature?
> > If you remove it, Matrox boards will be initialized by both matroxfb and offb
> 
> If my board isn't seen by OF, then by taking Daniel's hack I only
> initialise once by matroxfb correct? So this is only a probelm if the card
> is seen by OF and another driver (in the case of a Mac/OF specific Matrox
> card)

What's Daniel's hack?

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Geert Uytterhoeven]

On Mon, 1 Feb 1999, Benjamin Herrenschmidt wrote:
> On Mon, Feb 1, 1999, Geert Uytterhoeven
> <Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:
> 
> >Since BootX creates a fake OF device tree, I suspect it to appear in the
> tree.
> >Can you use your Mystique under MacOS? This is of course a prerequisite for
> >BootX seeing your board.
> 
> OF in the machine's ROM (not the card's ROM) should make _any_ PCI board
> visible provided that it contains correct config-space registers with a
> vendorID and a deviceID, which is required for all PCI cards anyway. The

I'd expect that, too. But my DawiControl DC-2976UW Sym875 SCSI board doesn't
show up in /pci, while my S3 Vision968 is visible as /pci/display. Both boards
don't have OF ROMs.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Owen Waller]

Hi,

> > > > (my PReP does not have OF and I never saw it...) If you uncommented #define
> > > > above, be sure that you commented out complement part from
> > > > drivers/video/offb.c - otherwise matroxfb can be initialized twice, thus
> > > > you'll get two fb's per one hardware :-(
> > > Is there any way that this could be changed? I don't need my internal
> > > video (control) to work, but I'd rather have it and the matrox compiled
> > > into the one kernel without a hack. Unless Geert you know some way of
> > > "fudging" an non-OF card into the OF device tree? OR Petr could you
> > > possibly work in a #define construct so that Daniel's "hack" became
> > > official? (mind you neither of these are very general solutions).
> > There is a problem. What if you HAVE matrox in OF ? Of course,
> Yes, Mac Matrox boards appear in the OF tree.

o.k. well the x86 board definelty doesn't... So we now have a more general
problem:

If I have two idential video boards in my Mac one "mac" specific which
shows up in the OF tree, and one that is x86 sourced and doesn't show up
under OF how can we initialise both boards correctly.

> > I remove this #ifdef from driver and add some variable to ensure, that
> > driver will be initialized only once... And if matroxfb is not your primary

im my case matroxfb will become my primary head, but I'd still like access
to the internal (control) video in case soemthing in a new kernel dies
before matroxfb is initialised.

> > head, you can, as temporary solution, compile it as module. It should
> > work without problems then.
> This is indeed a problem. We should use something like request_region() to
> claim the space used by the board. That way we can make sure each board is
> initialized only once. Boards that are left uninitialized and that appear in
> the OF tree should be handled by offb as a last resort.

Geert, I'm not sure what you are saying here. So you mean that an non-OF
board whould "somehow" be initialised by another driver, and then the OF
tree checked for uninitialised devices? Which in this case would
presumably be the other "mac" specific video board. 

> > > Also does anybody know how this situation changes if you use BootX to boot
> > > (I don't so I can't comment on this). Would BootX map the mystique from
> > As I do not have anything with OF around here, tell me what you want
> > and I'll do it...
> Since BootX creates a fake OF device tree, I suspect it to appear in the tree.
> Can you use your Mystique under MacOS? This is of course a prerequisite for
> BootX seeing your board.

Nope, the card isn't seen (AFAIK) by MacOS. The card was designed for x86
systems so there never was an MacOS driver for it. So unless BootX does
something very fancy when it builds an OF device tree, I guess it would
miss it too.

> > P.P.S.: Should not I remove whole #ifdef CONFIG_FB_OF from driver?
> > Is there anybody who uses this additional feature?
> If you remove it, Matrox boards will be initialized by both matroxfb and offb

If my board isn't seen by OF, then by taking Daniel's hack I only
initialise once by matroxfb correct? So this is only a probelm if the card
is seen by OF and another driver (in the case of a Mac/OF specific Matrox
card)

> (unless you disable offb completely, but then other boards like control are no
> longer found), which is not what we want.

Exactly.

-------------------------------------------------------------------------
Owen Waller                     |   "...sometimes I think I'm a little
PhD. Student in Control Eng.    |    more English than I am French..."
Queens University               |              - Alain Prost 
Belfast                         |
Tele: +44 (0)1232 274085        |    Fax: +44 (0)1232 667023


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Geert Uytterhoeven]

On Mon, 1 Feb 1999, Petr Vandrovec Ing. VTEI wrote:
> On  1 Feb 99 at 15:30, Owen Waller wrote:
> > o.k. well the x86 board definelty doesn't... So we now have a more general
> > problem:
> > If I have two idential video boards in my Mac one "mac" specific which
> > shows up in the OF tree, and one that is x86 sourced and doesn't show up
> > under OF how can we initialise both boards correctly.
> If you have at least one matrox in your OF tree, driver will initialize
> all matroxes from offb. If you have no matrox in OF tree, driver will
> initialize them from matrox_init.
> > im my case matroxfb will become my primary head, but I'd still like access
> > to the internal (control) video in case soemthing in a new kernel dies
> > before matroxfb is initialised.
> Without offb you can set order by
> video=control: video=matrox:
> to get control first (or vice versa to get matrox first). With offb I do not
> know.
> 
> So, attached patch adds back that matrox_init is called unless you
> specify `video=matrox:off' on command line. In this case, matrox can
> be still initialized through offb. If you specify `video=matrox:disabled',
> driver will be unavailable for offb too.

Which does not help if you have 2 Matrox boards, due to the single static
`initialized' variable.

> Also, driver still does not use device_node passed to driver by offb
> because of no-one told me what I can expect in that variable... Driver

You can find the PCI base addresses in there (look at atyfb_of_init() for an
example).

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Petr Vandrovec Ing. VTEI]

[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 1697 bytes --]

On  1 Feb 99 at 15:30, Owen Waller wrote:
> o.k. well the x86 board definelty doesn't... So we now have a more general
> problem:
> If I have two idential video boards in my Mac one "mac" specific which
> shows up in the OF tree, and one that is x86 sourced and doesn't show up
> under OF how can we initialise both boards correctly.
If you have at least one matrox in your OF tree, driver will initialize
all matroxes from offb. If you have no matrox in OF tree, driver will
initialize them from matrox_init.
> im my case matroxfb will become my primary head, but I'd still like access
> to the internal (control) video in case soemthing in a new kernel dies
> before matroxfb is initialised.
Without offb you can set order by
video=control: video=matrox:
to get control first (or vice versa to get matrox first). With offb I do not
know.

So, attached patch adds back that matrox_init is called unless you
specify `video=matrox:off' on command line. In this case, matrox can
be still initialized through offb. If you specify `video=matrox:disabled',
driver will be unavailable for offb too.
Also, driver still does not use device_node passed to driver by offb
because of no-one told me what I can expect in that variable... Driver
uses nvram_read_byte(NV_VMODE & NV_CMODE) to set initial resolution if
offb is enabled.
                                    Best regards,
                                        Petr Vandrovec
                                        vandrove@vc.cvut.cz

P.S.: I hope that your list survive this 890 bytes long attachment.
P.P.S.: As usual, cc-me if you have comments/question/...
P.P.P.S.: If patch will not apply cleanly, apply Geert's scr_readw()
patches first.

[-- Attachment #2: Text from file 'OW' --]
[-- Type: text/plain, Size: 890 bytes --]

--- linux-2.2.1.dist/drivers/video/matroxfb.c	Fri Jan 15 22:56:49 1999
+++ linux/drivers/video/matroxfb.c	Mon Feb  1 16:55:56 1999
@@ -4,7 +4,7 @@
  *
  * (c) 1998,1999 Petr Vandrovec <vandrove@vc.cvut.cz>
  *
- * Version: 1.9 1999/01/04
+ * Version: 1.13 1999/02/01
  *
  * MTRR stuff: 1998 Tom Rini <tmrini@ntplx.net>
  *
@@ -5743,20 +5748,26 @@
 }
 
 #ifndef MODULE
+static int __init initialized = 0;
+
 __initfunc(void matroxfb_init(void))
 {
 	DBG("matroxfb_init")
-#if defined(CONFIG_FB_OF)
-/* Nothing to do, must be called from offb */
-#else	
-	matrox_init();
-#endif
+	
+	if (!initialized) {
+		initialized = 1;
+		matrox_init();
+	}
 }
 
 #if defined(CONFIG_FB_OF)
 __initfunc(int matrox_of_init(struct device_node *dp)) {
 	DBG("matrox_of_init");
-	matrox_init();
+	
+	if (!initialized) {
+		initialized = 1;
+		matrox_init();
+	}
 	if (!fb_list) return -ENXIO;
 	return 0;
 }

Re: matroxfb, anybody? (More details...)

[Petr Vandrovec Ing. VTEI]

On  1 Feb 99 at 18:15, Geert Uytterhoeven wrote:
> > So, attached patch adds back that matrox_init is called unless you
> > specify `video=matrox:off' on command line. In this case, matrox can
> > be still initialized through offb. If you specify `video=matrox:disabled',
> > driver will be unavailable for offb too.
> Which does not help if you have 2 Matrox boards, due to the single static
> `initialized' variable.
No problem because of driver initializes ALL matroxes once matrox_init is
called, regardless of device_node contents (behavior is determined by
video=matrox:dev:X parameter).
> > Also, driver still does not use device_node passed to driver by offb
> > because of no-one told me what I can expect in that variable... Driver
> You can find the PCI base addresses in there (look at atyfb_of_init() for an
> example).
Unless `register_pci_region' is here, I think that I stay with current
behavior. I'm too lazy to add skipping of already registered devices
into matrox_init().
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Benjamin Herrenschmidt]

On Mon, Feb 1, 1999, Owen Waller <O.Waller@ee.qub.ac.uk> wrote:

>If I have two idential video boards in my Mac one "mac" specific which
>shows up in the OF tree, and one that is x86 sourced and doesn't show up
>under OF how can we initialise both boards correctly.

It will not appear in OF as a display device and may not appear with a
name, but are you sure it doesn't appear at all under it's generic
pciXXXX,YYYY name ? (where XXXX is the vendorID and YYYY the deviceID).


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Owen Waller]

hi,

> >If I have two idential video boards in my Mac one "mac" specific which
> >shows up in the OF tree, and one that is x86 sourced and doesn't show up
> >under OF how can we initialise both boards correctly.
> It will not appear in OF as a display device and may not appear with a
> name, but are you sure it doesn't appear at all under it's generic
> pciXXXX,YYYY name ? (where XXXX is the vendorID and YYYY the deviceID).

I don't think so but I'll double check tonight.

Thanks

-------------------------------------------------------------------------
Owen Waller                     |   "...sometimes I think I'm a little
PhD. Student in Control Eng.    |    more English than I am French..."
Queens University               |              - Alain Prost 
Belfast                         |
Tele: +44 (0)1232 274085        |    Fax: +44 (0)1232 667023


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Owen Waller]

On Mon, 1 Feb 1999, Geert Uytterhoeven wrote:

> On Mon, 1 Feb 1999, Petr Vandrovec Ing. VTEI wrote:
> > On  1 Feb 99 at 15:30, Owen Waller wrote:
> > > o.k. well the x86 board definelty doesn't... So we now have a more general
> > > problem:
> > > If I have two idential video boards in my Mac one "mac" specific which
> > > shows up in the OF tree, and one that is x86 sourced and doesn't show up
> > > under OF how can we initialise both boards correctly.
> > If you have at least one matrox in your OF tree, driver will initialize
> > all matroxes from offb. If you have no matrox in OF tree, driver will
> > initialize them from matrox_init.
> > > im my case matroxfb will become my primary head, but I'd still like access
> > > to the internal (control) video in case soemthing in a new kernel dies
> > > before matroxfb is initialised.
> > Without offb you can set order by
> > video=control: video=matrox:
> > to get control first (or vice versa to get matrox first). With offb I do not
> > know.
> > So, attached patch adds back that matrox_init is called unless you
> > specify `video=matrox:off' on command line. In this case, matrox can
> > be still initialized through offb. If you specify `video=matrox:disabled',
> > driver will be unavailable for offb too.
> Which does not help if you have 2 Matrox boards, due to the single static
> `initialized' variable.

True. In this case is it worth applying your patch Petr?

> > Also, driver still does not use device_node passed to driver by offb
> > because of no-one told me what I can expect in that variable... Driver
> You can find the PCI base addresses in there (look at atyfb_of_init() for an
> example).

if you know the base address in PCI could this be used to move the card
into OF?

-------------------------------------------------------------------------
Owen Waller                     |   "...sometimes I think I'm a little
PhD. Student in Control Eng.    |    more English than I am French..."
Queens University               |              - Alain Prost 
Belfast                         |
Tele: +44 (0)1232 274085        |    Fax: +44 (0)1232 667023


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[dhiltgen@toocool.calpoly.edu]

OK, I've made a bit more progress...

Using con2fb makes the console switching much happier...  I associated
tty2 to matrox and left the rest on control.  The tty2 console didn't
move immediately; I had to run fbset -i -fb /dev/fb1 on tty2 (still
visually on control) at which point it popped over to matrox.  From then
on I could switch back and forth and everything worked as expected.

The cursor tends to get messed up on matrox... a second "large"
multi-color funky cursor square (about 4x larger) exists after an fbset.
As soon as I switch consoles back to control, the cursor cleared back up.
(This was consistent every time I ran fbset.)

Scrolling is still messed up.  When the matrox scrolls off the end,
control gets the scroll action.  Again, if I switch consoles things get
reset as they should be. ^L will also clean it up temporarily.

I can get two X servers started, and I tried to use "X :0 tty1" for one
of them and "X :1 tty2" for the other, but I can't get them to co-exist
happily.  The first one always takes tty7.  I even tried "-keeptty" as
it sounded like it might force the X server to stick to the initial tty
instead of 7.  Bottom line:  I can switch from either one to console,
but I can only get back to the first one that I started through
tty7. (Either matrox or control but never both)

Also, only the active X server is "alive."  The second one just freezes
as if it thinks it lost the console to a VC switch.... not the desired
result.  So is this an X server issue, (Should ignore the VC switch) or a
kernel issue?  Sounds like a kernel issue, as the kernel should realize
that the X server still has the framebuffer, and therefore should still
"think" that it is active.  If no-one speaks up I might go hacking next
week and see if I can cludge something to get it to the point where both
X servers get console data...  Geert, any thoughts?

So, two questions.    

1) How can I get the two X servers to use different VCs so that I can 
switch between them.  Alternatively...

2) Is there any way to get the mouse to "fall off" one side and end
up on the other X server (Like Sun's with multiple heads.)  XFree86 4.0
maybe?  Is it even close to usable yet if I signed up to be a developer,
or is it really messy right now?

Oh, and I've downloaded 3.3.3 and applied the SVGA patch and it didn't
build out of the box (unrelated to the patch, looks like ppc issues with
other parts of the build.)  I haven't started tweaking yet but as soon
as I get some more free time I'll see if I can get it to build.



Note:  All of this was without passing any kernel parameters.  I'm now
running with "video=matrox:vesa:0x11a,nopan,fv:80" and only using the
matrox buffer and it works great as /dev/fb0.  Now all I have to do is
get that darn accelerated X server working. ;)   Of course if I try to do
stuff with control (/dev/fb1 now) things start getting screwy again.

Thanks.

-- 
Daniel Kerry Hiltgen     Computer Science     Cal Poly, San Luis Obispo, CA  
dhiltgen@www.itslab.calpoly.edu    http://www.itslab.calpoly.edu/~dhiltgen/

"In a world without fences who needs Gates?"  1997 JavaOne Conference

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Petr Vandrovec Ing. VTEI]

On  2 Feb 99 at 2:37, dhiltgen@toocool.calpoly.edu wrote:
> Using con2fb makes the console switching much happier...  I associated
> tty2 to matrox and left the rest on control.  The tty2 console didn't
> move immediately; I had to run fbset -i -fb /dev/fb1 on tty2 (still
You have some problem somewhere. If I do (atyfb + matroxfb or vga16fb +
matroxfb):
<switch to tty2>
con2fb /dev/fb1 /dev/tty2
then immediately at this point contents of screen on atyfb/vga16fb is
frozen and output on matroxfb is activated. Without any intervening
fbset, of course. I hope, that resolution on controlfb is compatible
with matroxfb capabilities (i.e. 8-32 bpp, 4bpp only on Millennium I/II).
> The cursor tends to get messed up on matrox... a second "large"
> multi-color funky cursor square (about 4x larger) exists after an fbset.
Could it be forgotten fbcon software cursor (flashing box 1x1 character)?
It could be also 32x32 pixels uninitialized hardware cursor, but I do not
know why driver should forget to initialize it.
> Scrolling is still messed up.  When the matrox scrolls off the end,
> control gets the scroll action.  Again, if I switch consoles things get
> reset as they should be. ^L will also clean it up temporarily.
? Isn't it control problem? vgacon + matroxfb, vga16fb + matroxfb,
atyfb + matroxfb and matroxfb + matroxfb hapilly coexist here...
BTW, updates on non-fg framebuffer are suspended until you switch
to that framebuffer.
> I can get two X servers started, and I tried to use "X :0 tty1" for one
> of them and "X :1 tty2" for the other, but I can't get them to co-exist.
> happily.  The first one always takes tty7.  I even tried "-keeptty" as
> it sounded like it might force the X server to stick to the initial tty
> instead of 7.  Bottom line:  I can switch from either one to console,
> but I can only get back to the first one that I started through
> tty7. (Either matrox or control but never both)
It could be on tty8. And I think that you want to run `X vt2 :1'
(I hope that it is not fbdev specific option).
> Also, only the active X server is "alive."  The second one just freezes
> as if it thinks it lost the console to a VC switch.... not the desired
> result.  So is this an X server issue, (Should ignore the VC switch) or a
> kernel issue?  Sounds like a kernel issue, as the kernel should realize
It is kernel issue. At least, it send signals about getting/loosing fg
terminal on every console switch.
> 1) How can I get the two X servers to use different VCs so that I can
> switch between them.  Alternatively...
I did "XF86_Mach64 & ; XF86_SVGA :1 &" just now and I got
Mach64 server running (on top of vga16fb) on /dev/tty24 and Matrox
running on /dev/tty25... /dev/tty24 is available here as right-alt-ctrl-F12,
/dev/tty25 as left-alt-ctrl-F1 + alt-left_arrow... Both hapilly working.
You can switch between them, but, of course, only one updates screen in
one moment. Because of I have dual-input EIZO, it does not cause problems
to me :-)
> 2) Is there any way to get the mouse to "fall off" one side and end
> up on the other X server (Like Sun's with multiple heads.)  XFree86 4.0
> maybe?  Is it even close to usable yet if I signed up to be a developer,
> or is it really messy right now?
I do not think that it is possible at this moment.
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz

> Note:  All of this was without passing any kernel parameters.  I'm now
> running with "video=matrox:vesa:0x11a,nopan,fv:80" and only using the
Why nopan? It must be slow as hell...

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Owen Waller]

On Mon, 1 Feb 1999, Benjamin Herrenschmidt wrote:
> On Mon, Feb 1, 1999, Owen Waller <O.Waller@ee.qub.ac.uk> wrote:
> >If I have two idential video boards in my Mac one "mac" specific which
> >shows up in the OF tree, and one that is x86 sourced and doesn't show up
> >under OF how can we initialise both boards correctly.
> It will not appear in OF as a display device and may not appear with a
> name, but are you sure it doesn't appear at all under it's generic
> pciXXXX,YYYY name ? (where XXXX is the vendorID and YYYY the deviceID).

well having checked this last night an x86 matrox board definatly doesn't
show up any where under /proc/device-tree. Theres no pciXXXX,YYYY type
listing. But the board is there /proc/pci.

So it looks like I have a similar situation to Geert, who also has a pci
board that doesn't show up under OF.

Cheers

-------------------------------------------------------------------------
Owen Waller                     |   "...sometimes I think I'm a little
PhD. Student in Control Eng.    |    more English than I am French..."
Queens University               |              - Alain Prost 
Belfast                         |
Tele: +44 (0)1232 274085        |    Fax: +44 (0)1232 667023


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Owen Waller]

On Mon, 1 Feb 1999, Geert Uytterhoeven wrote:
 
> On Mon, 1 Feb 1999, Benjamin Herrenschmidt wrote:
> > On Mon, Feb 1, 1999, Geert Uytterhoeven
> > <Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:
> > >Since BootX creates a fake OF device tree, I suspect it to appear in the
> > tree.
> > >Can you use your Mystique under MacOS? This is of course a prerequisite for
> > >BootX seeing your board.
> > OF in the machine's ROM (not the card's ROM) should make _any_ PCI board
> > visible provided that it contains correct config-space registers with a
> > vendorID and a deviceID, which is required for all PCI cards anyway. The
> I'd expect that, too. But my DawiControl DC-2976UW Sym875 SCSI board doesn't
> show up in /pci, while my S3 Vision968 is visible as /pci/display. Both boards
> don't have OF ROMs.

Geert, do either of these cards show up under your OF tree? I wouldn't
expect so as theyt don't have an OF rom (like my mystique) but I am
curious.

Cheers

-------------------------------------------------------------------------
Owen Waller                     |   "...sometimes I think I'm a little
PhD. Student in Control Eng.    |    more English than I am French..."
Queens University               |              - Alain Prost 
Belfast                         |
Tele: +44 (0)1232 274085        |    Fax: +44 (0)1232 667023


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Geert Uytterhoeven]

On Tue, 2 Feb 1999, Owen Waller wrote:
> On Mon, 1 Feb 1999, Geert Uytterhoeven wrote:
> > On Mon, 1 Feb 1999, Benjamin Herrenschmidt wrote:
> > > On Mon, Feb 1, 1999, Geert Uytterhoeven
> > > <Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:
> > > >Since BootX creates a fake OF device tree, I suspect it to appear in the
> > > tree.
> > > >Can you use your Mystique under MacOS? This is of course a prerequisite for
> > > >BootX seeing your board.
> > > OF in the machine's ROM (not the card's ROM) should make _any_ PCI board
> > > visible provided that it contains correct config-space registers with a
> > > vendorID and a deviceID, which is required for all PCI cards anyway. The
> > I'd expect that, too. But my DawiControl DC-2976UW Sym875 SCSI board doesn't
> > show up in /pci, while my S3 Vision968 is visible as /pci/display. Both boards
> > don't have OF ROMs.
> 
> Geert, do either of these cards show up under your OF tree? I wouldn't
> expect so as theyt don't have an OF rom (like my mystique) but I am
> curious.

The SCSI board doesn't show up, the S3 bideo board is /pci/display. My DEC21041
Ethernet board is /pci/ethernet.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[dhiltgen@toocool.calpoly.edu]

On Tue, Feb 02, 1999 at 12:53:20PM +0000, Petr Vandrovec Ing. VTEI wrote:
> On  2 Feb 99 at 2:37, dhiltgen@toocool.calpoly.edu wrote:
> > Using con2fb makes the console switching much happier...  I associated
> > tty2 to matrox and left the rest on control.  The tty2 console didn't
> > move immediately; I had to run fbset -i -fb /dev/fb1 on tty2 (still
> You have some problem somewhere. If I do (atyfb + matroxfb or vga16fb +

It gets weirder... ;)

> matroxfb):
> <switch to tty2>
> con2fb /dev/fb1 /dev/tty2
> then immediately at this point contents of screen on atyfb/vga16fb is
> frozen and output on matroxfb is activated. Without any intervening
> fbset, of course. I hope, that resolution on controlfb is compatible

Now that I'm running matrox as my primary display (/dev/fb0) , I tried
to fire up control this evening using the same technique (con2fb and fbset)
and I managed to panic my machine numerous times, yet I never got a
valid console on control (/dev/fb1).  I was going to try to play around
with getting two X servers running again, but I just couldn't get
it to be happy.  

> with matroxfb capabilities (i.e. 8-32 bpp, 4bpp only on Millennium I/II).

The real problem now is that whenever I do an fbset, the mode gets set 
for _both_ framebuffers, and the timings are not the same between the two.
I tried to pass the parameters to control at bootup hoping that 
would circumvent the problem by using:

append="video=matrox:vesa:0x11a,nopan,fv:80 video=control:vmode:6,cmode:32"

but either my syntax is wrong, or matrox overrides controls settings,
as I don't get a 640x480x32 mode on control.   It gets set to the same
mode as matrox, which can be confirmed with a fbset -i.

When I was running control as /dev/fb0, then I could get X to work
correctly only on /dev/fb0.  On fb1 it had a messed up color pallet,
and if I tried to change the mode/timings things just got all messed up.

Now that I have matrox as /dev/fb0, I can only get X to work properly
on that.  Control wont work properly.   Bummer. :(


> > The cursor tends to get messed up on matrox... a second "large"
> > multi-color funky cursor square (about 4x larger) exists after an fbset.
> Could it be forgotten fbcon software cursor (flashing box 1x1 character)?
> It could be also 32x32 pixels uninitialized hardware cursor, but I do not
> know why driver should forget to initialize it.

I'm voting for the uninitialized hardware cursor.  It definitely looks
like "random" bits of color.  With Matrox as /dev/fb0 this is no longer
present, and the scrolling anomaly isn't either.  Now if I could get a
darn console terminal on control then I could tell you what would happen
then, but I imagine things would get screwy again.

> > I can get two X servers started, and I tried to use "X :0 tty1" for one
> > of them and "X :1 tty2" for the other, but I can't get them to co-exist.
> > happily.  The first one always takes tty7.  I even tried "-keeptty" as
> > it sounded like it might force the X server to stick to the initial tty
> > instead of 7.  Bottom line:  I can switch from either one to console,
> > but I can only get back to the first one that I started through
> > tty7. (Either matrox or control but never both)
> It could be on tty8. And I think that you want to run `X vt2 :1'
> (I hope that it is not fbdev specific option).

I'll try this again soon, but I was unable to get anywhere today
with control.  After a few attempts X popped up on control, but using
matrox's mode settings and as a result was all messed up... two copies
side-by-side that each looked like half of an interlaced frame.  When
I tried to set a mode that was valid for control, I got a kernel panic.
Definitely some bugs in the kernel right now. :(

> > 2) Is there any way to get the mouse to "fall off" one side and end
> > up on the other X server (Like Sun's with multiple heads.)  XFree86 4.0
> > maybe?  Is it even close to usable yet if I signed up to be a developer,
> > or is it really messy right now?
> I do not think that it is possible at this moment.

Is this feature planned?  Anyone know?  I'd sure love to see it...

> > Note:  All of this was without passing any kernel parameters.  I'm now
> > running with "video=matrox:vesa:0x11a,nopan,fv:80" and only using the
> Why nopan? It must be slow as hell...

I don't like the panning window in X.  I want exactly the same virtual
window size as physical size.  ...and no, it's just fine.  Performance is
no different than if I run without nopan.   Sometimes if I change the
vyres using fbset the performance does become hideously slow, but as
long as I use nopan at bootup time then it works fine.


So, given that it looks like it's kernel bugs at this point...
Is there anything I can do to help squash them?   Geert, is there
anything that I can do to help you find where the problems might be?
I'd be more than happy to beta-test patches for you, or if you point me
in a general direction I can start throwing printk's in to track down
what's going wrong.

Thanks everyone. :)

-- 
Daniel Kerry Hiltgen     Computer Science     Cal Poly, San Luis Obispo, CA  
dhiltgen@www.itslab.calpoly.edu    http://www.itslab.calpoly.edu/~dhiltgen/

"In a world without fences who needs Gates?"  1997 JavaOne Conference

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Takashi Oe]

Hi,

On Wed, 3 Feb 1999, dhiltgen@toocool.calpoly.edu wrote:

> I tried to pass the parameters to control at bootup hoping that 
> would circumvent the problem by using:
> 
> append="video=matrox:vesa:0x11a,nopan,fv:80 video=control:vmode:6,cmode:32"

I don't know about the latest vger source tree, but 2.2.1 from kernel.org
or 990201 vger source at linuxppc.cs.nmt.edu don't have the necessary
codes to support that for controlfb.  It probably makes no difference for
your problem, but you can try the patch below:

ftp://ppc.linux.or.jp/pub/users/toe/planb/patch-990128.diff.gz

This contains the patches (fbmem.c and controlfb.c) for setting boot time
options among other things.


Takashi Oe


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: matroxfb, anybody? (More details...)

[Gerd Knorr]

On Sun, 31 Jan 1999, Geert Uytterhoeven wrote:

> > As far I know, Geert got it to compile on ppc, but it's not working yet.
> 
> It crashes with a bus error. That is, the unaccelerated version. I
> don't have a Matrox, and I had to disable the ATI code because it
> contains inline ia32 assembler.
> 
> I think the bus error is related to trying to map the frame buffer
> using /dev/mem instead of /dev/fb0.

IMHO it is more likely that the Server tries to access some I/O ports
(probe for ISA-VGA or something like that) without having them mapped.
At least I ran into this problem while playing with 3.9Nz.

  Gerd



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]