Hi Ben:

I have a DEC 3000/400, also with dual frame buffers. Ihave, however, managed
to get X going on one of the framebuffers, but not both. I did the same as
you did, I guess the difference could be that the version of X that I used
was 3.3.6, rather than the 4.0.3 (or whatever) is in current. The HOWTO is
on that page at monash.edu.au (can't remember the exact URL off the top of
my head), just follow that, making sure to use an older release of NetBSD (I
used 1.5.1, because I already had burned that to CD, I guess I was just
lucky, because I had intended to burn 1.5.2 to CD but never got around to
it...).

Good luck, let us all know how you go.

Cheers,
Matthew van de Werken
Electronics Engineer
CSIRO Exploration & Mining - Gravity Group
1 Technology Court - Pullenvale - Qld - 4069 - AUSTRALIA
ph:  +61-7-3327 4685     fax:  +61-7-3327 4455
email:  matt.vandewerken@csiro.au


> -----Original Message-----
> From: Ben Thompson [mailto:thompsob18@optushome.com.au]
> Sent: Monday, 22 October 2001 3:44 AM
> To: port-alpha@netbsd.org
> Subject: Re: framebuffer on dec3000/300L
>
>
> Hi all,
>
> Sorry, this may be completely off-topic, as I'm really an
> amatuer here,
> hence please accept my apologies in advance for the somewhat
> desperate tone
> of this post...
>
> I have a DEC 3000/600 with dual turbochannel PMAGB-BA
> framebuffers, and I've
> been completely unable to get X running on either display.
>
> I've tried everything, from installing the tcwscons kernel
> (which works
> beautifully as a text console on the primary framebuffer, but
> still no X),
> to downloading the re-compliled X server from the
> monash.edu.au site (refer
> to related articles over the last few months), even compiling
> the X source
> from the NetBSD-current release from scratch - in short,
> despite my best
> (admittedly amatuer) efforts, I have been completely unable
> to get an X
> server running on my machine.
>
> Again, apologies for my ignorance, but I haven't quite
> understood all that
> has been posted in this thread - is any of this relevant to
> my predicament?
>
> I only ask, because I have been desperately trying to get an X server
> running on my Alpha for over two months; in fact, I've had to
> resort to
> asking Compaq if I can still purchase a Tru64 unix release
> that will solve
> my problems (no response so far... but as a PC/LAN support
> tech who works at
> a site populated mainly by Compaq servers, this is what I have come to
> expect from the esteemed owners of the what used to be
> Digital Equipment
> Corporation...).
>
> I embark on my journey into the Alpha world as a die-hard Intel
> FreeBSD/Linux enthusiast, and I'd be the first to proclaim
> the numerous
> benefits of open-source software, however after my
> experiences to date, I'm
> really clutching at straws here.... In short, I'd be grateful
> for any help
> you can offer!
>
> Regards,
>
> Ben.
>
> ----- Original Message -----
> From: "Toru Nishimura" <locore32@gaea.ocn.ne.jp>
> To: <port-alpha@netbsd.org>
> Sent: Sunday, October 21, 2001 4:42 PM
> Subject: Re: framebuffer on dec3000/300L
>
>
> > Michael =?iso-8859-1?Q?B=E4rwolff?= <mb@g-zwo.de> said
> >
> > >> I have no clue this moment about how Andy approached "dual
> > >> head"-ness of Xserver which may provide :0.1 screen besides :0.0.
> > >
> > > Ok, other question. Is it posible to turn off the onboard
> framebuffer?
> >
> > It should not be necessary to turn off onboard framebuffer to use
> > X-window with another one sitting on TC option slot.   As you have
> > already experienced, DEC3000 choose a framebuffer on TC option slot
> > for a video console if it was equipped.   Then X server
> must run on the
> > video console.
> >
> > Some more complication resides in how NetBSD probes TC devices.
> > The order is reversed.   I donno the reason why dev/tc/tc.c is coded
> > in that way.  TC video console selection will follow a
> simple rule.  Video
> > console is assigned for a framebuffer sitting in lower
> numbered TC slot.
> > If you fill two HX boards in your 300L,  TC slot 0 will be
> a console.
> > NetBSD orders them reserse.  The HX will be wsdisplay 2 (probed 3rd)
> > in this case.
> >
> > More awkwardness would come from WSCONS design.   It'd require
> > to have special /dev/ entry to manipulate 2nd/3rd wsdisplay.  You
> > need to mknod with minor number +256 (I figured it out from src).
> >
> > So, I think it'd be better to;
> > - assign wsdisplay0 always for a real video console.
> > - have a standard way to allow dual-head configuration as
> well as the
> > orthgonal idea of virtual console on a single display.
> >
> > Tohru Nishimura
> >
>