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