Re: Comments on fbgen.c and fbcon-accel.c

["Michel Dänzer" <michel@daenzer.net>]

On Sat, 2002-05-04 at 20:01, Antonino Daplas wrote: 
> On Sat, 2002-05-04 at 05:47, James Simmons wrote:
> > 
> > > I have a few observations on fbgen and fbcon-accel.
> 
> One more thing I've noticed with gen_set_var.  Basically, gen_set_var
> will proceed if it satisfies 2 conditions -- during initialization (con
> < 0) and if the new var is different from the old var.  
> 
> The above is fine if everything is done in the console.  However,
> problems may arise if an app that touches the graphics hardware (ie X)
> is launched.  From the point of view of fbcon, the hardware state hasn't
> changed (compare of newvar with oldvar is false) when display is
> switched back to console.  And if that app did not fully restore the
> hardware state,  we will be left with a corrupted display.
> 
> So, it's probably better if set_par() and pan_display() are allowed to
> proceed unconditionally within gen_set_var.  It might take a few more
> milliseconds to switch consoles each time, but we are assured that the
> hardware state is always coherent with the current var.
> 
> What do you think?

I think this is giving away an advantage. The X server is a bad example
as it can use the framebuffer device fine.

If it's really a problem, maybe we could figure out a way to detect when
it's safe to optimize stuff away or as a last resort make it an option?


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net