> In article <6d4t28$ns8$2@grits.visus.com>,
> Jason McMullan <jmcc@pepsi.visus.com> wrote:
> >Michael Schmitz <schmitzm@uclink4.berkeley.edu> wrote with confidence:
> >> At 3:20 PM +0000 2/26/98, Jason McMullan wrote:
> >>> * (PC) Treat the keyboard/PS2 ports as `funny' serial ports.
> >>> * (Mac) ADB simply becomes a collection of serial ports
> >
> >> No, please don't do that. ADB is a bit more complex than a simple serial
> >> port. Please leave the default ADB keyboard and mouse input mechanisms
> >> unchanged, or extend the driver in a way that will work with just one mouse
> >> and one keyboard as it does now. Without requiring EvStack, that is.
> >
> > Sorry, I was being very niave about ADB - it was just an example.
> >The change I am proposing would amount to:
>
> Why is GGI messing around with the keyboard at all? I wasn't convinced
> about GGI before, but messing around with a keyboard makes me less and
> less optimistic about the dang thing.
It's related to system I/O and consoles.
And the current console system is inadequate to handling multiheaded
displays or complex I/O devices (such as two keyboards present).
EvStack attempts to solve this by allowing the binding of devices to
consoles (and console groups) as well as allowing different console
drivers.
While I can see this could be a bone of contention, the system in no way
requires a keyboard + mouse to be tied to the display. Unlike Windows95
for instance, which will crash if either are missing (from experience on
lots of computers here - it's my job to fix the thingies).
AFAIK no keyboard, mouse, or videodisplay is actually required. None.
Just like some patched linux-kernels out there (or 2.1.x with
serial-console enabled).
Though a last comment:
If it's not already obvious, EvStack is still very much in design
stage (barely alpha). It's meant to solve a number of
shortcomings in Linux, but these are neither relevant nor
important at this time. As you've suggested a number of times.
There WAS a discussion about a year or two ago that led to the EvStack
project - mostly problems with device management that was relegated to the
background as "too complicated - would take too long to build and besides
the current scheme works". I don't remember all the details, but IMHO
when EvStack is complete (it IS a seperate package from GGI -
more-or-less) it would probably be a good thing for a _TEST_ kernel.
It adds user/kernelspace paging communications and reorganizes some
devices in (imho) a more efficient and scalable form.
I could describe any of these comments, but things aren't advanced enough
to really flesh out much more. I run EvStack kernels most of the time and
am experimenting with userspace forms of some drivers (mouse and console).
I'm sorry this is so long a message but hope this will explain some things
better.
G'day, eh? :)
- Teunis
Summary : EvStack (messing with keyboard) is NOT KGI (GGI). It's being
built by people who think this should be done. It will probably end up
being either required by KGI or optionally supported by KGI. The system
is modular enough to handle it either way.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu