Subject: Re: framebuffer on dec3000/300L
To: None <firstname.lastname@example.org>
From: Toru Nishimura <email@example.com>
Date: 10/21/2001 15:42:30
Michael =?iso-8859-1?Q?B=E4rwolff?= <firstname.lastname@example.org> 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
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.