Re: [Linux-fbdev-devel] Comments on fbgen.c and fbcon-accel.c

[Antonino D. <ad...@po...>]

On Tue, 2002-05-07 at 16:00, Geert Uytterhoeven wrote:
> > 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.
> 

In the same token, then the kernel should be made as robust as
possible.  I would rather have a user app crash than have it lock-up the
hardware or corrupt the display.
 
> > 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;
>       }
>   }
> 

Actually, What I'm trying to point out is that gen_set_var() is not even
given a chance to call set_par().  If the generic interface is to be
adopted, it has to satisfy the requirements of most, if not all cards.

My current thinking is to let gen_set_var() call set_par()
unconditionally and at the same time pass a parameter or set a flag.
This flag or parameter can be something like, "yes, you really need to
set the hardware" or "no, var has not changed but you have the option to
set the hardware or not." Something to this effect:

if (memcmp(oldvar, newvar, sizeof(struct fb_var_screeninfo)))
	info->fbops->fb_set_par(info, 1);
else 
	info->fbops->fb_set_par(info, 0);

> > 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

I can't agree with you more.  When I was writing the i810/i815 fb
driver, I also modified the XFree86 i810 driver so it is fbdev-aware.
The "fbdev-awareness" is not a requirement, but it solves a lot of
problems and lessened code bloat.

But as you've said, they're hardcore :)

> fbdev if it's present. Fbdev is part of the kernel API. Circumventing the API
> is bad behavior.
> 

Which is why I abandoned that idea. 

Tony