Alex Zepeda wrote:
> On Wed, 28 Jul 1999, Colin Wood wrote:
> 
> > so my little LED routines actually work?  that's good to hear.  the reason
> > why they're currently #ifdef'd out is that they were causing some
> > interesting hangs on my system the last time i looked at it.  it didn't
> > happen all the time, but sometimes it just wouldn't come back...yuck!
> 
> Well I managed to reliably hang my system with them.  Some spl frobing and
> setting the "completion variable" to zero has solved most of the problems. 

you've really gotta watch mucking with the spl in the ADB code.  you can
easily hang things that way, and rather screw up over interrupt latency as
well if you're not careful.

> So far, this requires the true blue Mac ROM routines; weird things are
> happening with the direct code. 

yeah, we probably don't have something quite right.  and it's also
probably worse on some machines than on others :-)
 
> > > Scroll Lock is over F14, and Num Lock over clear; should I even bother
> > > with those?
> > 
> > well, i wouldn't really bother, since i'm not too sure what the proper
> > sequence is to even get scroll lock or numlock, even under macos.
> 
> Neither am I; *but* scroll lock is a rather useful thing under Unix,
> perhaps this would be more useful with wscons.  Num Lock is just
> pointless, because the number pad has no arrow markings on it. 

true.

> > i'd really suggest that you wrap all the LED frobbing code with an
> > 
> > 	if ((sc->origaddr == ADBADDR_KBD) && (sc->handler_id == ADB_EXTKBD)) {
> > 	}
> > 
> > otherwise you might wind up doing something a little screwy.
> 
> Ahh, and I figured I could get away with being extra lazy :^)

ah, but we'll have to train you out of that, won't we :-)

> The way it's setup now, it seems like only a keyboard event could trigger
> the LED frobbing code. 

well, the intention was to add a set of ioctl()'s to do it.  i doubt that
i've got it in there right now, but my local code has something like this:

int
kbdioctl(v, cmd, data, flag, p)
        void    *v;
        int     cmd;
        caddr_t data;
        int     flag;
        struct proc *p;
{
        struct kbd_softc *sc = v;
        int error = 0;

        switch (cmd) {
        case KIOCTYPE:  /* Get keyboard type */
                *(int *)data = sc->handler_id;
        case KIOCSLED:
                error = setleds(sc, *(u_char *)data);
                break;
        case KIOCGLED:
                *(int *)data = sc->sc_leds;
                break;
        default:
                error = (EINVAL);
        }
        return (error);
}

when we go to wscons, this will actually need to be changed slightly
since the kbd won't handle the ioctl directly.  i believe that i have code
to do that as well, tho.  keep in mind that a lot of the driver will need
to change slightly when we go to wscons (including a shared ADB driver
between the macppc and mac68k ports, i hope).

later.

colin