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
>