From: Paul Mundt <lethal@linux-sh.org>
To: adaplas@pol.net
Cc: linux-fbdev-devel@lists.sourceforge.net
Subject: Re: Re: [PATCH][RFC] Add support for Epson S1D13806 FB
Date: Tue, 15 Mar 2005 09:17:35 +0200 [thread overview]
Message-ID: <20050315071735.GA5037@linux-sh.org> (raw)
In-Reply-To: <200503142306.00236.adaplas@hotpop.com>
[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]
On Mon, Mar 14, 2005 at 11:06:00PM +0800, Antonino A. Daplas wrote:
> In the case of hitfb, fillrect and copyarea are both accelerated. So the proper flags would
> be:
>
> FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN | FBINFO_HWACCEL_COPYAREA |
> FBINFO_HWACCEL_FILLRECT.
>
Should this not be implied by having something other then the cfb_
routines for these? On the other hand, will this affect performance
negatively if these flags remain and we end up wrapping to the cfb_
routines in certain cases?
If we consider the case of FBINFO_HWACCEL_COPYAREA:
if ((cap & FBINFO_HWACCEL_COPYAREA) &&
!(cap & FBINFO_HWACCEL_DISABLED))
p->scrollmode = SCROLL_MOVE;
else /* default to something safe */
p->scrollmode = SCROLL_REDRAW;
This doesn't seem like it will work out well if we end up having
something like (using neofb as an example):
static void
neofb_copyarea(struct fb_info *info, const struct fb_copyarea *area)
{
switch (info->fix.accel) {
case FB_ACCEL_NEOMAGIC_NM2200:
case FB_ACCEL_NEOMAGIC_NM2230:
case FB_ACCEL_NEOMAGIC_NM2360:
case FB_ACCEL_NEOMAGIC_NM2380:
neo2200_copyarea(info, area);
break;
default:
cfb_copyarea(info, area);
break;
}
}
The behaviour in this case will be to use SCROLL_MOVE with regards to
cfb_copyarea() instead of SCROLL_REDRAW as it would normally. If we trust
the comment, then this seems unsafe or broken.
In this case it would seem to be more sensible to fix neo_alloc_fb_info()
to only set these flags for those devices where an optimization exists.
In the case of where using the optimized method depends on a fixed bit
depth, this issue becomes a bit more problematic.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-03-15 7:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-14 10:13 [PATCH][RFC] Add support for Epson S1D13806 FB Thibaut VARENE
2005-03-14 12:15 ` Antonino A. Daplas
2005-03-14 13:00 ` Thibaut VARENE
2005-03-14 13:13 ` Antonino A. Daplas
2005-03-14 14:10 ` Antonino A. Daplas
2005-03-14 14:24 ` Thibaut VARENE
2005-03-14 15:06 ` Antonino A. Daplas
2005-03-14 14:35 ` Paul Mundt
2005-03-14 15:06 ` Antonino A. Daplas
2005-03-15 7:17 ` Paul Mundt [this message]
2005-03-15 10:26 ` Antonino A. Daplas
2005-03-14 15:18 ` Antonino A. Daplas
2005-03-14 13:18 ` Paul Mundt
2005-03-14 13:25 ` Geert Uytterhoeven
2005-03-14 13:34 ` Thibaut VARENE
2005-03-14 13:53 ` Antonino A. Daplas
2005-03-14 14:09 ` Thibaut VARENE
2005-03-14 14:12 ` Thibaut VARENE
2005-03-14 13:44 ` Paul Mundt
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=20050315071735.GA5037@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=adaplas@pol.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.