>Number:         8603
>Category:       kern
>Synopsis:       wscons wsmux changes in august broke X on macppc
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Oct 10 11:57:00 1999
>Last-Modified:
>Originator:     Erik Bertelsen
>Organization:
	
>Release:        NetBSD-current ca. 17 Aug until 10 Oct 1999
>Environment:
System: NetBSD rlanarh108.uni-c.dk 1.4L NetBSD 1.4L (HJEMME) #205: Sun Oct 10 18:25:15 CEST 1999     erik@rlanarh108.uni-c.dk:/home/src/sys/arch/macppc/compile/HJEMME macppc


>Description:
	After the wsmux related changes in August, X will no longer start
	on my macppc.
	The symptom is that that X does not start and that /var/log/xdm
	contains the message

 		X: open kbd/mouse: No such fil eor directory

	Additional debug prints shows that the attempt to open 
	/dev/wskbd0 in osvendorinit gives EBUSY.

	I send this as a kern PR, but I'm not really sure whether it
	should be port-macppc.

	The following is an extract of a conversation on port-macppc and
	on tech-kern related to this problem (the patch to wskbd.c still
	makes X functional):

From: Bill Studenmund <wrstuden@nas.nasa.gov>
cc: Andreas Wrede <andreas@planix.com>, port-macppc@netbsd.org
Subject: Re: wscons problems on macppc, was -current on PowerBook G3/400

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

***********************

Subject: Re: wscons problems on macppc, was -current on PowerBook G3/400
From: cgd@netbsd.org (Chris G. Demetriou)
Date: 22 Sep 1999 11:21:07 -0700

Bill Studenmund <wrstuden@nas.nasa.gov> writes:
> 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:
> [ ... ]

Well, I can't say for sure what the 'right' answer is, but if wscons
now requires that you have multiple virtual terminals for X to work
properly, or even assumes that you'll have multiple virtual terminals,
that's very losing...


*********************************

From: Matthias Drochner <drochner@zel459.zel.kfa-juelich.de>


wrstuden@nas.nasa.gov said:
> > diff -r1.1.1.27 wskbd.c
> > 560c560
> > < #if NWSMUX > 0 || NWSDISPLAY > 0
> > ---
> > > #if NWSMUX > 0 

That's a wsmux issue - this should be quite independent from
the virtual screen stuff.
(I've got some problems with wsmux too, but didn't have time
to understand how things are supposed to work.)

> I think the problem is that the wscons code kinda assumes that X will run
> on one of the ttyE's (typically ttyE4)

No, wscons doesn't assume this. At least on i386, X runs
with only the console screen (what you get with wscons
not enabled in /etc/rc.conf).

>         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.

That's for simplicity of the display driver. X can take over the
one and only screen -- at least wscons allows it.

best regards
Matthias

*********************************************
From: Bill Studenmund <wrstuden@nas.nasa.gov>

On Wed, 22 Sep 1999, Matthias Drochner wrote:

> 
> wrstuden@nas.nasa.gov said:
> > > diff -r1.1.1.27 wskbd.c
> > > 560c560
> > > < #if NWSMUX > 0 || NWSDISPLAY > 0
> > > ---
> > > > #if NWSMUX > 0 
> 
> That's a wsmux issue - this should be quite independent from
> the virtual screen stuff.
> (I've got some problems with wsmux too, but didn't have time
> to understand how things are supposed to work.)

Well, it's getting in the way. :-)

> > I think the problem is that the wscons code kinda assumes that X will run
> > on one of the ttyE's (typically ttyE4)
> 
> No, wscons doesn't assume this. At least on i386, X runs
> with only the console screen (what you get with wscons
> not enabled in /etc/rc.conf).

I'll try this on macppc.

> >         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.
> 
> That's for simplicity of the display driver. X can take over the
> one and only screen -- at least wscons allows it.

wscons in general might, but I get busy errors with the mux stuff. both
wskbd1 (the real keyboard) and wskbd (the mux of it) all report EBUSY to
the x server. :-(

Take care,

Bill

***********************************

From: Bill Studenmund <wrstuden@nas.nasa.gov>

On Wed, 22 Sep 1999, Bill Studenmund wrote:

> On Wed, 22 Sep 1999, Matthias Drochner wrote:
> 
> > wrstuden@nas.nasa.gov said:
> > > I think the problem is that the wscons code kinda assumes that X will run
> > > on one of the ttyE's (typically ttyE4)
> > 
> > No, wscons doesn't assume this. At least on i386, X runs
> > with only the console screen (what you get with wscons
> > not enabled in /etc/rc.conf).
> 
> I'll try this on macppc.

It didn't work (running w/o wscons enabled). With the muxing around, I
always get EBUSY from the keyboards (either wskbd or wskbd1, the real
kbd). 

Thoughts?

Take care,

Bill

***********************************

From: Matthias Drochner <drochner@zel459.zel.kfa-juelich.de>

wrstuden@nas.nasa.gov said:
> It didn't work (running w/o wscons enabled). With the muxing around, I
> always get EBUSY from the keyboards (either wskbd or wskbd1, the real
> kbd).  

As I said, these should be unrelated things. The keyboard / mux
code doesn't know how many screens are allocated - there will
always be only one logical keyboard instance. (The X server is
supposed to close() the wskbd if its screen is switched away from.)

As I said, I had problems with wsmux too - I always got
EBUSY when I tried to get screenblank(1) working.
I'm afraid the reference count logics is broken, but
at the moment I don't have time to look at it.

best regards
Matthias

*********************************
From: Bill Studenmund <wrstuden@nas.nasa.gov>

On Thu, 23 Sep 1999, Matthias Drochner wrote:

> wrstuden@nas.nasa.gov said:
> > It didn't work (running w/o wscons enabled). With the muxing around, I
> > always get EBUSY from the keyboards (either wskbd or wskbd1, the real
> > kbd).  
> 
> As I said, these should be unrelated things. The keyboard / mux
> code doesn't know how many screens are allocated - there will
> always be only one logical keyboard instance. (The X server is
> supposed to close() the wskbd if its screen is switched away from.)

I agree that they SHOULD be unrelated things. :-) I just think that right
now they aren't. ;-) To the extent that I suspect the muxing expects that
demultiplexing to different users will happen in the ttyE? code (by
switching to different virtual screens). But in order to get different
screens, you need to be able to allocate screens. :-)

> As I said, I had problems with wsmux too - I always got
> EBUSY when I tried to get screenblank(1) working.
> I'm afraid the reference count logics is broken, but
> at the moment I don't have time to look at it.

Sounds like the same thing. :-)

Take care,

Bill

>How-To-Repeat:
>Fix:

- Erik Bertelsen
>Audit-Trail:
>Unformatted: