• Messages sorted by: [ date ][ thread ][ subject ][ author ] [ Next ]
• [ Previous ] Maybe in reply to: John C. Randolph

These are questions and comments promted by several of the notes on this subject.

Is there a source of information on the LCD of the display hardware?

Is some display hardware able to do its work in system RAM, or at least deliver its work product in system RAM? If so the display card just becomes another processor accessible to domain code via capabilities to prepare bit rasters for delivery, by capability, to the screen. This sounds like a lot of work.

A few year ago I studied the X windows protocol and it was oblivious to security. Any task could corrupt any window. That doesnnot mean that a capability version could not be invented.

For paranoid customers it would be good to have an alternate bare-bones display ability, accessible by a "secure attention button", via which he could talk to the TCB. This is sort of like the Unix systems that may dump you into ROM code.I wasn't thinking that bare-bones, however.

It is slick to include the display buffer in the checkpoint. We did this on the Luna port. Upon power-up the the display bufer data would be copied back from disk to the buffer. Like a Potemkin village, the code of the various windows would be brought in upon demand.

In addition the Luna Keykos had a command line style display service that did not involve the ROM code as the latter was scarcely documented.

Can someone recomend an architectural intro to OpenGL? One that includes such information as to where the hardware fits in the scheme? Norman Hardy <http://www.mediacity.com/~norm>

[ Next ]
• [ Previous ] Maybe in reply to: John C. Randolph