fb accel capabilities - second draft of patches coming

fb accel capabilities - second draft of patches coming

[David Eger]

After trying a third batch of driver conversion (this time the matrox/ drivers),
I've decided my first-draft fb accel capabilities patch is flawed... so while i
  re-work them, please send me your thoughts...

In the first pass (these past five patches), I had:

#define FB_HWACCEL_DISABLED     0x0000
#define FB_HWACCEL_COPYAREA     0x0001
#define FB_HWACCEL_FILLRECT     0x0002
#define FB_HWACCEL_ROTATE       0x0004

The problem here is that the DISABLED functionality -- turning acceleration off
-- is orthogonal to whether a driver knows how to frob the accel engine.  So
for a second try, I'm taking the ever-present "noaccel" variable, and making it
a separate flag, as follows:

#define FB_HWACCEL_CAPABILITIES_MASk 0x0FFF
#define FB_HWACCEL_NONE         0x0000
#define FB_HWACCEL_COPYAREA     0x0001
#define FB_HWACCEL_FILLRECT     0x0002
#define FB_HWACCEL_ROTATE       0x0004
#define FB_HWACCEL_IMAGEBLIT    0x0008

#define FB_HWACCEL_DISABLED     0x8000

Still, some capabilities are advertized elsewise: being able to pan or wrap are
indicated by non-zero values in fix.xpanstep, fix.ypanstep, and fix.ywrapstep. 
I'm somewhat inclined to duplicate this information in the .hwaccel field (as,
for instance, the divides() macro in fbcon misinterprets the current
implementation)... so say:

#define FB_HWACCEL_XPAN         0x0010
#define FB_HWACCEL_YPAN         0x0020
#define FB_HWACCEL_YWRAP        0x0040
#define FB_HWACCEL_READSFAST    0x0080 /* software copying is usually faster
than re-r
endering */

Comments before I dive in for a second round?

-dte

ps, geert - i'm just now grokking var.vmode -- as an implisit extra
   argument to pan_display()... i can't decide whether it's a horrible hack,
   or just a warm reminder of closures in the lambda calculus...



-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: fb accel capabilities - second draft of patches coming

[Geert Uytterhoeven]

On Thu, 13 May 2004, David Eger wrote:
> ps, geert - i'm just now grokking var.vmode -- as an implisit extra
>    argument to pan_display()... i can't decide whether it's a horrible hack,
>    or just a warm reminder of closures in the lambda calculus...

It's a horrible hack meant to be used by fbcon only. IIRC I didn't add it ;-)

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


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click