From: Antonino Daplas <adaplas@pol.net>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Linux Fbdev development list <linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: LCD scaling type
Date: 11 Jan 2003 14:58:18 +0800 [thread overview]
Message-ID: <1042268184.932.165.camel@localhost.localdomain> (raw)
In-Reply-To: <1042227743.705.22.camel@zion.wanadoo.fr>
On Sat, 2003-01-11 at 03:42, Benjamin Herrenschmidt wrote:
> Hi !
>
> When setting a mode on an LCD display that is not exactly the
> native mode of that display, we can, on some chips, setup a
> scaler. However, most of the time, we have 2 difference choices
> for setting up this scaler: It can preserve or not preserve
> the aspect ratio. A typical example is the titnium powerbook's 1152x768
> mode. If I set it to 1024x768, I can get either horizontal scaling (not
> preserving aspect ratio) or no scaling with black bars on left & right
> (preserving aspect ratio).
>
> While in most case you actually want to preserve the aspect ratio, it
> would still I beleive make sense to let the user choose it.
>
> Could we define one of the reserved fields in fb_var_screeninfo as
> beeing a "flags" field for such things ? There are a couple of other
> things that we may want to stuff into such a bitfield later, I'd suggest
> reserving one 32 bits field for such flags.
>
I second to this. It's useful to have an extra field in
fb_var_screeninfo for drivers to play around. It's like an extension
field and its main use is to expose a hardware capability which is
uncommon enough to warrant generic support. It's meaning will vary from
driver to driver.
I also have a couple of things that come to mind (like switching from
truecolor to directcolor and vice versa without rebooting). I currently
use var->nonstd which is probably not the the right thing to do.
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 7:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-10 19:42 LCD scaling type Benjamin Herrenschmidt
2003-01-11 6:58 ` Antonino Daplas [this message]
2003-01-11 9:47 ` Benjamin Herrenschmidt
2003-01-11 10:16 ` Antonino Daplas
2003-01-11 11:08 ` Benjamin Herrenschmidt
2003-01-11 11:35 ` Antonino Daplas
2003-01-11 12:08 ` Benjamin Herrenschmidt
2003-01-11 12:42 ` Antonino Daplas
2003-01-11 13:29 ` Geert Uytterhoeven
2003-01-11 13:27 ` 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=1042268184.932.165.camel@localhost.localdomain \
--to=adaplas@pol.net \
--cc=benh@kernel.crashing.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.