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: 11 Jan 2003 13:12:10 +0800 [thread overview]
Message-ID: <1042261388.932.141.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44.0301101936110.18287-100000@phoenix.infradead.org>
On Sat, 2003-01-11 at 03:39, James Simmons wrote:
>
> > > I thought about this. Originally I did have this function but removed it.
> > > WHat do you think Geert?
> >
> > Yes, that's OK.
> >
> > But I was most concerned about fb_ops.fb_imageblit(), since clipping impacts
> > fb_image.data as well. IIRC, all (most?) current clipping implementations
> > modify fb_image.{dx,dy,width,height} only, without updating fb_image.data.
>
> Good point. Of course we could ignore pieces of data in that image instead
> of altering the data. Altering the entire data would be expensive.
>
> > > > 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.
> >
> > Well, in between the calls to fb_ops.fb_check_var() and fb_ops.set_par() you
> > can still perform that check. But it's indeed ugly.
>
> Altering to the framebuffer via /dev/fb that would effect the tty should
> not remain after the final close of /dev/fb. Instead the console should
> reset to its previous state before we first opened /dev/fb.
>
Right :-) I believe this is nearer the correct solution. Clipping is
typically used to maximize graphics/video bandwidth, but fbcon is using
it to "cover up" possible bugs in the code.
If we can have a correctly working fbcon, without the clipping code, it
will be proof to its robustness.
So, basically, on the first open we save xres, yres, xres_virtual,
yres_virtual and bits_per_pixel, and restore them on the last close, is
this correct? Any other parameters that will affect the actual and
virtual window size?
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-11 5:22 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 ` Antonino Daplas [this message]
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=1042261388.932.141.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.