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:

quoted

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. :(

quoted

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.

quoted

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. :(

quoted

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...

quoted

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 ]]