Subject: virtual framebuffer
To: None <port-mac68k@netbsd.org>
From: Mattias Sandstrom <mattias@beauty.se>
List: port-mac68k
Date: 11/19/2002 21:59:08
hey,

ok, time for another wild suggestion from my tired brain. i was 
wondering if it would be possible to modify dt to provide a "throughput 
interface" to the framebuffer device so that i can run other framebuffer 
programs at the same time, like x or links (after i'm done porting it)? 
is this possible to do in userland without kernel support? i guess 
wscons is really the right place to add this, like the i386 unices seem 
to have (alt+fx), but kernel programming is just too much for me and 
it's very hard to get your code used if you have to more or less 
officially add it to the distribution first.

here's what i was thinking: when a program tries to open the framebuffer 
device, dt creates an offscreen buffer the same size as the screen and 
then reports the screen address to the calling program as either the 
buffer or the real screen depending on what terminal is active. this 
would require the calling program to check the screen address every time 
it wants to draw to it, but it seems like this is something any well 
written piece of software should anyway? if this doesn't work i can live 
without the offscreen buffer and just send a suspend signal to the 
program before i switch to another terminal and a resume signal when i 
switch back. sounds like a good plan or not? any ideas?

thanks,

	/matt