On Tue, Mar 19, 2002 at 09:06:33PM -0500, Roland McGrath wrote: > 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.
I have pondered this a bit, and want to start to go into some details of this. I think the next step is hacking the current console to work at all, but I want to plan ahead in parallel. When seperating the code like this, we have to have an interface between the generic screen matrix and the display driver. This interface should be filesystem based, asynchronous, and flexible enough to allow efficient implementation of display drivers. So we will have a mmap'able file which contains the screen content, line by line from the top left to the bottom right. The screen dimensions can be retrieved with the tioctl_tiocswinsz RPC. That much is pretty clear. Now, there are a variety of issues. 1. Asynchronous update information. We have the file_notice_changes RPC for that. For example, FILE_CHANGED_WRITE can be used to signal changes, FILE_CHANGED_META can probably be used to signal size changes (if we don't want to use the signal mechanism for that) etc. However, I would like to add a new type here, FILE_CHANGED_SCREEN_RECTANGLE, to signal that a rectangular area on the screen changed. The start and end position define the upper left and lower right corner of the rectangular area. And, I would also like to have scrolling types, FILE_CHANGED_SCREEN_RECTANGLE_SCROLLED_UP, etc, for two reasons: Scrolling can usually be optimized heavily on the display driver side, it is useful information to have to implement the update. Also important, for some display drivers, like drivers for Braille terminals, it would be very good to know about scrolling, because then the Braille terminals panning window can be adjusted so that the scrolling does not actually occur. This would be an improvement over using a STOP signal or a special button which implements something similar to STOP on the display driver side. (This is actually a feature request by Stephane Doyon, a BRLTTY developer, who is actually a user of such devices). 2. Scroll back buffer. It seems to me best to have the scroll back buffer maintained in the generic component, so it is retained across detach/attach and can be shared by many display drivers. This requires that it is part of the mmap'able file, so far no problem. The actual screen content would be at the end, which can be determined because the dimensions are known. Here, a SCROLLED_UP notification is also very useful, because this is the most common thing for a scrollback buffer to do. However, I was a bit too quick by saying that the screen content is at the end of the file. Because this causes a serious performance problem: Scrolling requires the whole file to change, and indeed, because the file is mapped, we would need to move the whole buffer by one line. This is not acceptable. It would be much better to treat the file as a ring buffer, and provide the first line of the screen content by some other means. Then scrolling is easily achieved by clearing the next line in the buffer and changing the metadata to point to one line lower (wrapping at the end). However, this causes the problem that we need to pass metadata to the caller. Maybe an RPC is necessary for that, maybe the two unused fields in winsize can be overloaded (ugly, ugly), maybe somewhere else we have a suitable field to overload? It doesn't seem so. The length of the file can change. When we clear the scrollback buffer, the file will shrink to a screen full of data, when then new data is put into it, the file will be extended. We have notification messages for that. Maybe by being a bit more clever we can always make use of them? But I don't see a way right now. 3. Asynchronous updates again. I have thought about a different issues, and that is if display drivers should alwas get synchronous update info, or if multiple rapid changes should be collected into a single notification message. This can make the display driver "sluggish", but it improves performance in cases like where a lot of data scrolls over the screen. Maybe there should be options to fine tune such behaviour, maybe it should be "intelligent" (eg, make it more synchronous when the user is typing, and less synchronous when data is scrolling by, as far as you can detect this). Maybe the timing can be chosen in a way to avoid the bad side effects. We know from the X Window system how asynchronous updates look and feel, although I am sure that people would be surprised to see this effect on the text console (I usually switch this feature off in an xterm, because I often eye-ball flooding text for things I am looking for). There are probably more points that I forgot now, but the above are probably a good start to talk about such issues. Let me know if I am completely off the track. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
