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
next 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).