An application that would show pixels to a local person on a conventional display negotiates for a V-window. To the application the V-window is merely a writable segment that may be mapped into an address space or whatever else you do to a segment in order to write bits into it. Attached to the V-window is a V-keeper that is trusted and in cahoots with the owner of the hardware pixel buffer. At strategic times (see below) pixels are copied from the V-window to the corresponding screen window. The application puts its pixels into the V-window and they soon show up on the screen.
A pixel stride and line count is negotiated when the V-window is created. A bit-blt will copy to the screen even if the strides are different or the pixel depths don’t match.
Each page of the V-window can be in one of two states that I will call open and closed here. An open page is actually writable by the application. A page never stays open long, perhaps at most a second. This frequency may be controlled by the person at the display. A closed page is actually read only to the application. The pixels in a closed page match whatever visible pixels there are on the screen. When the application stores into a closed page the segment keeper of the V-window (part of the V-keeper) opens the window immediately and starts a timer. When the timer expires it closes the window and copies the bits to the screen. Pages of the V-window with no corresponding visible pixels may remain open. When the application is not changing the V-window, those pages may remain closed. The V-window can be used by the screen manager to recall revealed pixels as other windows are moved or closed.
Note that the when application reads the V-window it always sees the last thing that it wrote there. It is not a covert input channel. A conventional segment keeper has all of the authority necessary to do all of this. No kernel hooks are required except for keys to the pages of the hardware pixel buffers.