Our chief concern to begin with is clean code reuse and consistency of the terminal emulation for standard display devices. Turning the interface inside out doesn't lose that.
But I am still on the fence about what the proper structure really is. First are some feature concerns, with a garnish of efficiency concerns that are no doubt in fact negligible. There are several things you get from having the virtual terminal (the screen matrix) maintained in a common layer independent of and "above" any particular display driver. The negligible efficiency concern is that you avoid duplication of the data structures and the processing code path that maintain the screen matrix and the state of escape sequence parsing. You can have generic visual bell and screensaver modules that plug in at the higher level interface. They could use the character drawing interfaces or use the escape sequence engine to do whatever (play ascii movies, towers of hanoi, etc); the generic part can implement save/restore state, and also inspection of the matrix so you can do ascii decayscreen and the like. Such hacks would work the same for any underlying display driver(s) you might have (presumably a display driver could have its own fancier graphics things and those would take over instead when turned on). Similarly, you could have things like split-screen display of two virtual terminals implemented generically at this layer (i.e. an interface like "window" or newer versions of "screen"). You can dynamically detach and attach display drivers to a virtual screen. New ones attaching can reconstruct the current screen matrix immediately from the higher layer's state. (The only other way is to replay an arbitrarily long log of the output to process the escape sequences--but in the general case you might need the entire output history.) I see uses for both the case of additional disparate display drivers attaching to spy on another display, and the case of maintaining the virtual terminal screen matrix while having no display driver attached at all, to be displayed when one attaches. There is surely more than one way to structure the code such that these things are possible. But all I have in mind at the moment is the imposition of the central terminal emulation module. Second, I am still of two minds about what "the right thing" is for the console abstraction (actually, I'm two minds aware that in the end my mind will just go to little pieces). I was buying your argument for a while, thinking about applications a la conserver where you are treating the virtual console as you would a serial port (i.e. equivalent to a pty), as well as the speech/Braille examples you mentioned. But now I am thinking more of applications a la screen, where there is a consistent virtual terminal screen image maintained that can be attached (sequentially or simultaneously) to multiple disparate players. And for speech and Braille interfaces, they might well have a virtual screen image in the canonical sense and have in their own front ends scrolling or "panning" sort of interfaces (screen has support for some Braille devices that appear to work this way). Ultimately where this should be heading is libchannel. We want to decompose the functionality we're implementing and provide flexible forms of interconnection. For example, say I have 11 physical displays. On each of the first 10 physical displays I would like to have 12 virtual terminals and switch among those with hot keys. On the 11th physical display I would like to be able to see virtual terminal #1 of each of the first 10 displays, and switch among those virtual terminals with hot keys. Now generalize from there. In the fully decomposed model, a terminal emulation module is a component that connects takes asynchronous input events (a stream of bytes) and on the other end provides a kind of storage interface (though one that delivers immediate updates asynchronously to asynchronous readers). You can stick this in the middle or not, depending on what configuration you want. All these features are more than fancy enough not to worry about overmuch now. It's fine to impose a different sort of structure for now that gets just the features you are working on now. Keeping all the new code clean and modular in the general sense means it won't be terribly painful to restructure it later. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
