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 20:42:27 +0800 [thread overview]
Message-ID: <1042288803.977.83.camel@localhost.localdomain> (raw)
In-Reply-To: <1042286909.541.43.camel@zion.wanadoo.fr>
On Sat, 2003-01-11 at 20:08, Benjamin Herrenschmidt wrote:
>
> For my immediate need, however, I still think turning one of the
> reserved fields of var_screeninfo into a "mode_flags" would be useful,
> we can already define a FB_MFLAG_LCD_FULLSCALE flag that would ask the
> driver to not bother keeping aspect ratio (the idea here is that keeping
> aspect ratio is the default, so 0, even if that's nor really working yet
> in radeonfb or aty128fb).
>
I wasn't contradicting you. A new feature that can be supported by
different hardware and is quite useful deserves a unique flag, and I
definitely agree with that. I don't to see my desktop flattened top to
bottom if I can prevent it.
But aside from the above, I also need a field which is interpreted
differently from driver to driver, and is so nebulous that it doesn't
deserve its own flag. Just something that can be used to poke the
hardware from user space without writing a utility each time.
Currently, I'm doing this by setting bits in var->nonstd.
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 12:52 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
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 [this message]
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=1042288803.977.83.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 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).