On 7 May 2002, Antonino Daplas wrote:

On Tue, 2002-05-07 at 06:24, Michel Dänzer wrote:

quoted

On Sat, 2002-05-04 at 20:01, Antonino Daplas wrote: 

quoted

On Sat, 2002-05-04 at 05:47, James Simmons wrote:

quoted

quoted

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.

Which can be visible, especially if you reprogram the PLL...

quoted

quoted

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.

Indeed.

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. 

If you run an application that's not fbdev aware, behavior has always been
undefined.

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().

And set_par() could do some optimizations based on a shadow map of the register
contents, also to avoid artefacts when switching to a different VC with the
same video timings. Like:

  write_reg(reg, val)
  {
      if (shadow[reg] != val) {
	shadow[reg] = val;
	hardware[reg] = val;
      }
  }

quoted

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.

The problem is that most drivers in XFree86 don't _want_ to be fbdev compliant.
The solution is to convince the hardcode anti-fbdev XFree86 guys to use the
fbdev if it's present. Fbdev is part of the kernel API. Circumventing the API
is bad behavior.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


_______________________________________________________________

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