[Prev][Next][Index][Thread]
Re: Linux + SVGALIB
>>>>> "Ben" == Ben Lindstrom <mouring@netnet.net> writes:
Ben> Please go through your code and find places where the screen
Ben> in being updated (hopefully they are in one common place. =).
Here's the problem: many programs (mostly games) which people run
under Executor/svgalib bypass QuickDraw and write directly to screen
memory. We have no way of knowing when they will modify the screen.
The svgalib docs suggest that Executor will be suspended during a
console switch:
void vga_runinbackground( int stat )
Enable/disable background running of a graphics program
(1 = enable). Normally, the program is suspended while
not in the current virtual console. A program can only
safely run in the background if it doesn't do any video
access during this time.
Perhaps the SIGIO we get from mouse motion wakes us up and Executor
proceeds to write to the screen at a bad time? Or perhaps the
documentation is wrong?
The svgalib docs also discourage the use of the function I believe you
are advocating:
int vga_oktowrite()
Indicates whether the program is in the console currently
visible on the screen, that is, whether it is OK to write
to video memory (if running in the background has been allowed
with the function above). Note that this is not entirely
safe, since a console switch interrupt may occur during a
video operation. [best to avoid this function]
Ben> At least if you can figure out if your are doing massives
Ben> amount of screen graphics...lock the VT terminal focus. =)
I think your suggestion is a good one, even if it won't work for all
programs we emulate. I can lock the vc around where Executor itself
modifies screen memory. I wonder if locking the vc when we don't even
own the vc causes our process to stop until we have regained the vc?
We do hardward accelerated rect fills under svgalib...I wonder if
switching vc's after such an operation has been started could cause
problems.
I am also concerned that switching vc's to X windows will cause
problems because Executor still owns the mouse and keyboard devices.
Hmmm.
-Mat
Follow-Ups:
References: