From: Aki M Laukkanen <amlaukka@cc.helsinki.fi>
  To  : ggi-develop@eskimo.com
  Date: Sat, 19 Jun 1999 17:10:01 +0300 (EET DST)

Re: beta2.0b2.1 fixes

> special kernel command line (something like "vesafb=scroll") that

Yes, see my other reply for clarification. The kernel options are
"vesa:ypan" and "vesa:ywrap".

> >  +	if (!priv->orig_fix.ypanstep && mode->frames > 1) {
> >  +		mode->frames = 1;
> >  		err = -1;

> Are you sure that is the correct fix ?  To me that says: "if the
> _original_ mode cannot do panning, then the future one cannot as well",
> which I don't think is right in the general case (I must admit I've

That snippet is from GGI_fbdev_checkmode() and if I understood 
the code correctly priv->fix is not fetched until do_change_mode().

Besides if the driver is really so silly that it would return ypanstep
differently for different modes then it could just aswell be that the
ypanstep is zero for the current mode but not for the original mode.
All the other tests in that function refer to priv->orig_fix too.

> forgotten all the subtleties of the fbdev API -- anyone know if they
> have written a good API docco on it yet ?).

I only know about the one Geert wrote.

Btw. fbdev does not currently set a signal handler for the VT switch.
Is there a reason for it and would you accept a patch for it?

-- 
D.