linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antonino Daplas <adaplas@pol.net>
To: James Simmons <jsimmons@infradead.org>
Cc: Linux Fbdev development list
	<linux-fbdev-devel@lists.sourceforge.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [Linux-fbdev-devel] rotation.
Date: 10 Jan 2003 18:26:51 +0800	[thread overview]
Message-ID: <1042171520.933.126.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44.0301091949560.5660-100000@phoenix.infradead.org>

On Fri, 2003-01-10 at 03:54, James Simmons wrote:
> 
> > However, as Geert mentioned, if you want to support rotation
> > generically, then you have to do it in the fbcon level.  The driver need
> > not know if the display is rotated or not.  All it needs to do is fill a
> > region with color, color expand a bitmap and move blocks of data, and
> > optionally 'pan' the window.  Fbcon will pass the correct (ie, oriented)
> > information for the driver.
> 
> Yes. Hardware rotation shouldn't also not effect the way accel 
> operatations are done.
 
The main difference is if the hardware supports rotation, fbcon will
present it with "normal" data.  With the generic implementation, fbcon
will present the driver with rotated data.

So we need a driver capabilities field either in fb_info or
fb_fix_screeninfo.

> 
> > This will not be too processor intensive as long as some data is
> > prepared beforehand, like a rotated fontdata.
> 
> Yeap!! The only thing is we could end up with 4 times the amount of data.
>  

Not really.  We can dynamically rotate the fontdata using the default
display->fontdata into another buffer.  I believe I have functions that
do that in the patch I submitted.  (Sorry, I lost it when one of my
drives crashed :-(.

Tony

  reply	other threads:[~2003-01-10 10:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-07 22:44 rotation James Simmons
2003-01-08 10:24 ` rotation Geert Uytterhoeven
2003-01-08 10:48   ` rotation Sven Luther
2003-01-08 11:25     ` [Linux-fbdev-devel] " Måns Rullgård
2003-01-08 12:05       ` John Bradford
2003-01-08 12:55         ` Sven Luther
2003-01-09 19:45     ` [Linux-fbdev-devel] " James Simmons
2003-01-09 19:44   ` rotation James Simmons
2003-01-08 16:56 ` rotation Antonino Daplas
2003-01-09 19:54   ` [Linux-fbdev-devel] rotation James Simmons
2003-01-10 10:26     ` Antonino Daplas [this message]
2003-01-10 19:42       ` rotation James Simmons
2003-01-11  5:13         ` rotation 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=1042171520.933.126.camel@localhost.localdomain \
    --to=adaplas@pol.net \
    --cc=geert@linux-m68k.org \
    --cc=jsimmons@infradead.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /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).