Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Do I add or remove confusion if I say that the console server should support
> both models? The generic part of the console server would then always pass
> through without interpretation, the device specific part can either pass it
> on further to the actual hardware, or interprets it and breaks it down into
> hardware primitives like scrolling/filling etc.
That's the way it should be.
> > > [ console abstraction ]
> > > [ virtual console 1 ] [ virtual console 2 ] ...
> > > [ display driver ]
> > > [ generic display driver escape sequence handling ]
> > > [ display driver's support functions like scrolling ]
>
> Do I make sense?
I think so. My mental picture is more like
[virtual console n]
/ \ ----------------------- character streams
[tty driver] [escape code interpretation]
| ----------------------- screen operations
[screen driver]
The only difference, except for terminology, is that the screen driver
is an independent piece of code that need not be aware about what goes
on above it, and which uses a different interface than tty-style
drivers.
[ And if anyone can figure out a reasonable interface for doing that,
it would be nice if an applications could bypass both the terminfo
and the escape code interpretation, speaking directly to the screen
driver. Say a hacked curses library that implements scrolling by
sending an rpc to the console server, which invokes the
corresponding operation (if available) in the screen driver. ]
/Niels
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
