From: "Antonino A. Daplas" <adaplas@hotpop.com>
To: David Eger <eger@theboonies.us>, adaplas@pol.net
Cc: David Eger <eger@havoc.gtf.org>, Andrew Morton <akpm@osdl.org>,
linux-fbdev-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org,
Thomas Winischhofer <thomas@winischhofer.net>
Subject: Re: [Linux-fbdev-devel] [PATCH] fb accel capabilities (resend against 2.6.7-rc2)
Date: Fri, 4 Jun 2004 08:06:38 +0800 [thread overview]
Message-ID: <200406040806.18437.adaplas@hotpop.com> (raw)
In-Reply-To: <1086285678.40bf676e1da4d@mail.theboonies.us>
On Friday 04 June 2004 02:01, David Eger wrote:
>
> On the down side, panning makes screen corruption for me... time to
> investigate to see if fbcon or radeonfb is to blame... perhaps panning is
> just incompatible with accel engine at all in radeon...
>
The one time I saw screen corruption with panning was when the console virtual
rows (p->vrows in fbcon.c) were unconditionally set to var->yres_virtual/
fontheight. In most cases, this will cause screen corruption (or even a GPU
crash) when you scroll down to end of virtual memory. Symptoms are corrupted
data when you pan to p->vrows, fixed by changing to another console and back
again.
The correct thing to do is not to scroll to the very end, but scroll only to a
point where you still have enough fb memory at the end of fbmem to display 1
screenful of data. This is done by subtracting several lines to p->vrows as
illustrated by this code snippet scattered in fbcon.c
p->vrows = info->var.yres_virtual / vc->vc_font.height;
if(info->var.yres > (vc->vc_font.height * (vc->vc_rows + 1))) {
p->vrows -= (info->var.yres - (vc->vc_font.height * vc->vc_rows)) /
vc->vc_font.height;
}
Or this in fbcon_resize()
p->vrows = var.yres_virtual/fh;
if (var.yres > (fh * (height + 1)))
p->vrows -= (var.yres - (fh * height)) / fh;
The above code is scattered because we cannot seem to find a central location
to strategically place it because of the very confusing console code :-(
Is it possible that the changes in your development tree might have failed to
appropriately update p->vrows?
Tony
P.S. I believe this corruption was spotted with fix contributed by Thomas
last year.
next prev parent reply other threads:[~2004-06-04 0:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-03 2:36 [PATCH] fb accel capabilities (resend against 2.6.7-rc2) David Eger
2004-06-03 2:36 ` David Eger
2004-06-03 15:07 ` Antonino A. Daplas
2004-06-03 15:07 ` [Linux-fbdev-devel] " Antonino A. Daplas
2004-06-03 18:01 ` David Eger
2004-06-03 20:46 ` Thomas Winischhofer
2004-06-04 1:26 ` David Eger
2004-06-04 0:06 ` Antonino A. Daplas [this message]
2004-06-04 2:24 ` [PATCH] fbcon: prefer pan when available David Eger
2004-06-04 2:24 ` David Eger
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=200406040806.18437.adaplas@hotpop.com \
--to=adaplas@hotpop.com \
--cc=adaplas@pol.net \
--cc=akpm@osdl.org \
--cc=eger@havoc.gtf.org \
--cc=eger@theboonies.us \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=thomas@winischhofer.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.