Doh! forgot to add tech-kern to the list. Resending so followups go to
both lists.

I'm adding tech-kern to this thread as it's a problem of MI & MD code not
agreeing on what to do..

The problem is that the macppc wscons code hasn't kept track of changes in
the MI code, or that the MI code makes assumptions which aren't correct
for macppc. Those of us who want to use X are stuck in the middle..

On Wed, 22 Sep 1999, Erik Bertelsen wrote:

> On Tue, Sep 21, 1999 at 05:59:59PM -0400, Andreas Wrede wrote:
> > 2. X
>  This was discussed a few weeks ago on this mailing list. A fix was
> suggested by someone (I don't recall who). This fix was never committeed
> to the sources, but they work on my G3 DT 233MHz:
> 
> Index: wskbd.c
> ===================================================================
> RCS file: /home/cvs-base/src/sys/dev/wscons/wskbd.c,v
> retrieving revision 1.1.1.27
> diff -r1.1.1.27 wskbd.c
> 560c560
> < #if NWSMUX > 0 || NWSDISPLAY > 0
> ---
> > #if NWSMUX > 0
> 666c666
> < #if NWSMUX > 0 || NWSDISPLAY > 0
> ---
> > #if NWSMUX > 0
> 
> Another thing that was discussed that time was that you should not have
> a mux entry on the adb kbd conf line:
> 
> wskbd0  at akbd? console ?
> 
> With this the machine is happily running X.

My concern with this is that it's basically undoing recent changes to the
usb & wscons code. Without a mux entry on the wskbd line, I think we'll
default to NWSMUX not beign defiend as > 0, so the above change effectivly
backs out all the changes to the code. 

I think the problem is that the wscons code kinda assumes that X will run
on one of the ttyE's (typically ttyE4), whereas the macppc code only
supports one ttyE - ttyE0. Specifically, lines 331 & 332 of
sys/arch/macppc/dev/ofb.c are:

        if (sc->nscreens > 0) 
                return (ENOMEM); 

which seems to imply only one screen is ok. A comment below, "/* one and
only for now */" corroberates that.

So wscons guru's, what do we do?

Take care,

Bill