linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Eger <eger-sender-da68b9@theboonies.us>
To: Linux Frame Buffer Device Development
	<linux-fbdev-devel@lists.sourceforge.net>
Subject: fb accel capabilities - second draft of patches coming
Date: Thu, 13 May 2004 15:48:38 -0500	[thread overview]
Message-ID: <1084481318.40a3df264d552@mail.theboonies.us> (raw)

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

             reply	other threads:[~2004-05-13 20:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-13 20:48 David Eger [this message]
2004-05-14  9:39 ` fb accel capabilities - second draft of patches coming Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1084481318.40a3df264d552@mail.theboonies.us \
    --to=eger-sender-da68b9@theboonies.us \
    --cc=eger-dated-1085086121.170f6f@theboonies.us \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).