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
next prev parent 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 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.