From: Antonino Daplas <adaplas@pol.net>
To: James Simmons <jsimmons@infradead.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Linux Frame Buffer Device Development
<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: clipping
Date: 10 Jan 2003 18:27:27 +0800 [thread overview]
Message-ID: <1042172016.933.136.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44.0301092122450.5660-100000@phoenix.infradead.org>
On Fri, 2003-01-10 at 05:24, James Simmons wrote:
>
> > 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.
>
> I thought about this. Originally I did have this function but removed it.
> WHat do you think Geert?
>
> > 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.
>
> Yuck!!! The other way is better.
>
Yes, I thought so too :-).
I think one scenario why we need clipping is changing bits_per_pixel,
ie, changing from 8->16 will drop your vyres by half and it's difficult
to determine this unless you do another check before the set_par(), as
Geert mentioned. Worse still, there is little if no valid memory past
vyres but the console thinks there is. That's where you will get a
segfault.
Whereas explicitly doing fbset -vyres 768 will not cause a segfault,
because you still have valid framebuffer memory past y=768.
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-10 10: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 ` clipping Antonino Daplas
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 ` Antonino Daplas [this message]
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=1042172016.933.136.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.