Marcus Brinkmann <[EMAIL PROTECTED]> writes: > On Sun, Jun 02, 2002 at 03:00:15PM +0200, Niels Möller wrote: > > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > > > > VISUAL DISPLAY I \ / > > > VISUAL DISPLAY II | | TERM ON VIRTUAl CONSOLE I > > > ... > CONSOLE SERVER < TERM ON VIRTUAL CONSOLE II > > > INPUT DEVICE I | | ... > > > INPUT DEVICE II | | > > > ... / \ > > > > I take it the entries of the left hand side correspond to real > > devices? > > No, they are all programs (Hurd servers or clients). > > The visual display/input device client(s) handle the actual presentation of > the screen matrix to the user and feed the user input to the console server. > This is like the VNC client for example.
So if you have N virtual terminals, then you also have N instances of "display" and N instances of the "input". That makes it clearer. But what about the actual multiplexing of N virtual terminals onto 1 screen and keyboard? I thought that was also part of the console server, but now it seems that has to be a separate program. Which makes some sense, I just don't remember that being mentioned before. > I am not sure what you have in mind. Maybe it is useful to provide raw > write access to the text matrix in the console server. That's a nice-to-have thing. Consider an alternative curses backend that doesn' use the old fashined escape sequences. There may be other interesting uses (like, display hacks), but I guess it's not terribly important. > In this case, I > suggest: > > 1/console -> for term > 1/display -> r(w) to screen content > 1/input -> w(r) to input queue The only point of having display and input be children to the console node is that if I'm given only a port to the console (say, it's my process' stdin), I can easily get to the raw display with a single dir_lookup on that port. But one could of course use some other rpc for that, if needed. > There is no need to decide on a fixed width limit. You're right. I have forgotten much of the previous discussion, but now I think that the conclusion was that resize will be somewhat expensive, but that's no big problem because it doesn't happen very often. Regards, /Niels _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
