Pedigree

Much of the framework is now implemented.

• Cleanup when applications finish running - restore the TUI's terminal buffer to the console. Safe to do as all text output by the program will be on the terminal buffer, but graphics will be on a different buffer.
• Clean up VBE
• Get dropping to the debugger working with vmware-gfx
• Implement a cdi/video hook in terms of the framework. Write a vmware-gfx driver for CDI as a proof of concept. (This may mean adding stuff to cdi/video?) May need to talk to whoever was working on cdi/video originally to see where it was headed and where it's at now?

Done with post-application-run cleanup.

CDI/video stuff: git://git.tyndur.org/tyndur/alex.git

Dropping to the debugger works again.

Also, the child/parent relationship in the Framebuffer abstraction needs to be updated to specify a "currently active" chain.

eg (-> = new child):

Parent -> TUI -> TUI Terminal #1 -> Child 1
                -> TUI Terminal #2
                -> TUI Terminal #3

If the "TUI" framebuffer is not active, none of its children are ever rendered and draw operations are not passed to the top level (as the framebuffer is not flagged as "active").

1. The draw will go to the memory buffer for "Child 1", which is flagged as active.
2. The operation will be forwarded to "TUI Terminal #1", which is flagged as inactive. At this framebuffer the draw will be determined to have come from a child, so the memory will not be touched. The draw call will be dropped as the framebuffer is flagged as inactive.
3. The draw command is dropped, so nothing appears on the screen.

1. The draw will go to the memory buffer for "Child 1" and the draw call will be forwarded by "TUI Terminal #1" to TUI.
2. The "TUI" framebuffer will forward the call to the root framebuffer, at which point the draw will appear on the screen.

As soon as an inactive framebuffer is found on the chain, the call is dropped and the traversal of the chain ceases. This means framebuffers at the lowest level of the chain can be left flagged as active while parents are inactive. As soon as a framebuffer is marked active again all of its children are redrawn. Note that this child redraw traverses children's chains as well. This traversal is a depth-first traversal.

None of this has been implemented yet but will be needed to fix the case where switching between multiple consoles in the TUI at the moment doesn't hide the display of graphical applications.

Additionally, a method of IPC for applications to get a child framebuffer of a TUI terminal buffer would be good, so that graphical applications are properly sized and oriented within terminals (including clipping as required). Perhaps named framebuffers could work? Give a framebuffer a name and provide a system call to lookup the framebuffer from that name. This would be ideal for a GUI in the future too.

The active chain feature is no longer a requirement for Foster Milestone 1. It will come after Milestone 1 - the rest of the framework is enough for Milestone 1.