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

[Antonino Daplas <adaplas@pol.net>]

On Tue, 2002-05-07 at 06:24, Michel Dänzer wrote:
> 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.
I was talking of X running with it's own accelerated drivers.  I have
checked most of the X accelerated drivers, and most will just attempt to
restore the VGA registers and some when switching to the console.  I
think this is not just enough, since fb drivers require more than that. 
Simiarly, I have also looked at some of the fbdev drivers that are not
using the gen_* interface (nvidia, ati, matrox), and they will also
unconditially set the hardware during switches/set_var. The
fbgen_switch() function also calls fbhw->set_par() within do_set_var().
> 
> 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?
> 
I think if the gen_* interface is to be adopted, it will become a
problem. Detection is the best solution, but right now X and DRI do not
know that fb even exist so we can't get X to detect fb unless we
persuade the X people to do that.  I have tried X detection before by
checking the previous console number.  If the previous number is not a
valid console, we can presume that a non-console app used that.  But
this is not clean and there are too many conditions where this check
will fail. But then, I really don't understand the underlying console
interface, so an easier and more effective way may exist that I don't
know about.

Tony



_______________________________________________________________

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