On Sunday 30 May 2004 19:44, Thomas Winischhofer wrote:
> David Eger wrote:
> > I'll add some comments to the patch :)
> > The intent for the FBINFO_HWACCEL_fnName flags is to say that the
> > hardware will be smart about it (i.e., it ought to be fast). New fb
> > drivers have been filling in copyarea() with cfb_copyarea() (that is, the
> > software version) or more opaquely filling in copyarea() with their own
> > mydriver_copyarea(), and then conditionally calling cfb_copyarea()
> > depending on the noaccel flag.
> > With the patch, there are a bunch of these "is X really hardware
> > accelerated?" flags in fbinfo->flags, as well as FBINFO_HWACCEL_DISABLED
> > which should tell the driver to not use its acceleration engine --- and
> > use unaccelerated versions of copyarea(), fillrect(), imageblit(); and
> > FBINFO_MODULE (is the driver loaded as a module?)
> So far so good. Can't see a reason for partly disabling acceleration,
> but ok.
> >>Erm, I wasn't aware of this. Interesting... Personally, since sisfb does
> >>y-panning I didn't see any speed regressions compared with 2.4 yet.
> > So with my patch, you'd see a regression in speed until you flag that
> > your driver can do hardware panning. I thought it would be good for our
> > small brains to put all the flags for this in one place instead of
> > testing the (x/y)panstep variables for zero...
> There is another issue with panning. How does the new fbcon code decide
> how big the virtual screen shall be (if it cares at all)? Will there be
> a change in behavior?
There shouldn't be a change in behavior. The console virtual screen
(display->vrows) is still based on var->yres_virtual, which the driver should
set. fbcon also checks if var->ypanstep != 0 if the driver can do panning or
not. The main intent of the capability flags is choosing the best scrolling
mode. So in pseudo_code:
if (cannot_pan && fb_read_is_very_slow)
no_pan + redraw;
else if (cannot_pan && fb_read_is_fast)
no_pan + move;
else if (can_pan && fb_read_is_very_slow)
pan + redraw;
else /* pan + fb_read_is_fast */
pan + move;
/* an accelerated copyarea == fb_read is fast */
/* With PCI cards, fb_read is magnitudes slower than fb_write */
Of course, pan+redraw is still not supported by fbcon, so this resolves to
no_pan + redraw.
> Right now, this is more or less a hack: sisfb, unless explicitly told
> not to do so (nomax or noypan), will maximize the virtual y resolution
> on all var's it receives. DirectFB disables this "auto-maximizing"
> feature with a respective ioctl before changing the mode etc. Works
> fine. Dunno if other drivers do the same. Advantage is that users get
I think other drivers do the same. But syntax might be different, ie (if
var->yres_virtual == 0, then maximize var->yres_virtual, or something like
> the fastest possible console by default (without using fbset or the like
> to set the virtual screen size.)
> Do I have to expect this mechanism to fail? IOW: (No, not io-write, in
> other words ;)) Will the panning stuff change in the fbcon layer
> breaking this?
> >>Are these to set/cleared exclusively by the driver or must the driver
> >>expect them to change? (I mean for example that fbset in 2.4 could be
> >>used to disable acceleration, which is important to DirectFB)
The accel capability bits should be set/cleared exclusively by the driver
depending on it's capability (duh) or if var->accel_flags is set or not.
> > *really*? I was wondering about that. I'll have to go see how that
> > works...
> Assumingly simple. Set/clears FB_ACCELF_TEXT. DirectFB uses the same
> technique. Your new flags will break both.
The new flags should not break DirectFB if the driver correspondingly sets/
clears the capability bits depending on the setting of var->accel_flags.
> >>Is there any driver already finished so that I can look it up somewhere?
> > There's a patch for radeonfb (my video card ;-) )
> I already saw that. Will take a closer look.
> >>Will an old driver (status as of now) work at all with the new flags not
> >>being touched? Will it compile? (That *should* work IMHO)
> > /me nods. It should. I tried compiling all of the drivers, and most of
> > them compiled. The few drivers that didn't seemed to be pure 2.4 API
> > code that no one has loved for a long time :-/ Ah well..
> (Assume you mean 2.5 API...?)
> If they should compile you will need the mentioned compat-#define's in
> the long run...