Subject: Re: framebuffer on dec3000/300L
To: None <port-alpha@netbsd.org>
From: Toru Nishimura <locore32@gaea.ocn.ne.jp>
List: port-alpha
Date: 10/21/2001 15:42:30
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