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 at 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 at 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 at lists.linuxppc.org ]]