linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antonino Daplas <adaplas@pol.net>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: James Simmons <jsimmons@infradead.org>,
	Linux Frame Buffer Device Development
	<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: clipping
Date: 09 Jan 2003 00:26:28 +0800	[thread overview]
Message-ID: <1042043066.982.118.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.GSO.4.21.0301081053400.21171-100000@vervain.sonytel.be>

On Wed, 2003-01-08 at 17:54, Geert Uytterhoeven wrote:
> On Tue, 7 Jan 2003, James Simmons wrote:
> > > > > BTW, do we really need clipping in fb_ops.fb_{fillrect,copyarea,imageblit}()?
> > > > Personally, I don't think we need clipping.  I tried removing it before
> > > > (circa linux-2.5.30+), but the console segfaults whenever I decrease
> > > > var->yres_virtual.  I haven't tried this again with the newest
> > > > framebuffer framework though.
> > > 
> > > Any definitive answer on this?
> > > 
> > > What happens if you resize the VT to such a large size that columns*fontwidth >
> > > xres_virtual or rows*fontheight > yres_virtual? I guess clipping prevents a
> > > crash there?
> > 
> > Correct. Actually fbcon_resize checks to make sure the user doesn't do 
> > something stupid like this. So we might not needed. Hm.
> 
> And what if you use fbset to reduce the resolution below what's needed to
> accomodate the current console size?
> 
Then we do need clipping :-)  I think that happened to me, I just did
not recognize it.  I accidentally lowered the window size using fbset,
and suddenly I had a console where the tail end of each row of text
wraps to the next row.  I wasn't using cfb_imageblit then so this was
done by hardware.  If I was using cfb_imageblit, this will be clipped.

So, I think we do need clipping, but instead of implementing it in
fb_{fillrect,copyarea,imageblit}, we implement it higher up, in
accel_putcs() and family.  This should also protect drivers using 
hardware-based drawing. 

So perhaps, a function something like this:

void fb_clip(struct fb_fillrect *region, struct fb_fillrect *clip);

This should not be difficult to implement, and I'll code it if everyone
agrees.

The other option (which I don't like) is just to check the passed
fb_var_screeninfo in the put_var ioctl against the current console
window size.  But this is not foolproof as we will not be sure of the
resulting window size _after_ the fb_set_var() call.

Tony




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

  reply	other threads:[~2003-01-08 16:38 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-29 21:21 clipping Geert Uytterhoeven
2003-01-03 10:36 ` clipping Antonino Daplas
2003-01-07 21:08   ` clipping Geert Uytterhoeven
2003-01-07 22:13     ` clipping James Simmons
2003-01-08  9:54       ` clipping Geert Uytterhoeven
2003-01-08 16:26         ` Antonino Daplas [this message]
2003-01-09 21:24           ` clipping James Simmons
2003-01-09 21:46             ` clipping Geert Uytterhoeven
2003-01-10 13:55               ` [RESEND] clipping Antonino Daplas
2003-01-10 19:39               ` clipping James Simmons
2003-01-10 19:48                 ` clipping Geert Uytterhoeven
2003-01-11  5:12                 ` clipping Antonino Daplas
2003-01-10 10:27             ` clipping Antonino Daplas
2003-01-10 10:45               ` clipping Geert Uytterhoeven
2003-01-09 21:09         ` clipping James Simmons
     [not found] <1042172278.933.145.camel@localhost.localdomain>
2003-01-10 10:49 ` clipping Geert Uytterhoeven
     [not found] <Pine.LNX.4.44.0301102030310.30522-100000@phoenix.infradead.org>
2003-01-11  5:12 ` clipping Antonino Daplas

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=1042043066.982.118.camel@localhost.localdomain \
    --to=adaplas@pol.net \
    --cc=geert@linux-m68k.org \
    --cc=jsimmons@infradead.org \
    --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).