LCD scaling type

LCD scaling type

[Benjamin Herrenschmidt]

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.

Ben.

-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: LCD scaling type

[Antonino Daplas]

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

Re: LCD scaling type

[Benjamin Herrenschmidt]

On Sat, 2003-01-11 at 07:58, Antonino Daplas wrote:
> On Sat, 2003-01-11 at 03:42, Benjamin Herrenschmidt wrote:

> 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 don't fully agree here. While I agree a driver specific field might
be useful, I beleive the "flags" field should have defined meaning.

> 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.

For this too, defined flags would make sense as other driver might want
to implement the same capability, in which case we really want all of
them to do it the same way.

-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: LCD scaling type

[Antonino Daplas]

On Sat, 2003-01-11 at 17:47, Benjamin Herrenschmidt wrote:
> On Sat, 2003-01-11 at 07:58, Antonino Daplas wrote:
> > On Sat, 2003-01-11 at 03:42, Benjamin Herrenschmidt wrote:
> 
> > 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 don't fully agree here. While I agree a driver specific field might
> be useful, I beleive the "flags" field should have defined meaning.
> 
> > 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.
> 
> For this too, defined flags would make sense as other driver might want
> to implement the same capability, in which case we really want all of
> them to do it the same way.
> 

Well, yes of course, if a particular hardware feature is quite useful
and common, then you need something definitive.  But what I also want is
another field which will serve as a private communication channel
between userspace and driver. Adventurous users/testers can use them to
turn a unique hardware feature on/off.  This is similar to 'Tweak'ing
utilities common in MS Windows.

Tony



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: LCD scaling type

[Benjamin Herrenschmidt]

On Sat, 2003-01-11 at 11:16, Antonino Daplas wrote: 
> 
> Well, yes of course, if a particular hardware feature is quite useful
> and common, then you need something definitive.  But what I also want is
> another field which will serve as a private communication channel
> between userspace and driver. Adventurous users/testers can use them to
> turn a unique hardware feature on/off.  This is similar to 'Tweak'ing
> utilities common in MS Windows.

I already do that in some drivers using private ioctl's, though if
what you want is really an additional "feature" affecting a mode
setting, then it makes sense to fit it into fb_var_screeninfo

-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: LCD scaling type

[Antonino Daplas]

On Sat, 2003-01-11 at 19:08, Benjamin Herrenschmidt wrote:
> On Sat, 2003-01-11 at 11:16, Antonino Daplas wrote: 
> > 
> > Well, yes of course, if a particular hardware feature is quite useful
> > and common, then you need something definitive.  But what I also want is
> > another field which will serve as a private communication channel
> > between userspace and driver. Adventurous users/testers can use them to
> > turn a unique hardware feature on/off.  This is similar to 'Tweak'ing
> > utilities common in MS Windows.
> 
> I already do that in some drivers using private ioctl's, though if
> what you want is really an additional "feature" affecting a mode
> setting, then it makes sense to fit it into fb_var_screeninfo
> 

If you only need to do is turn something on or off, assigning it an
ioctl may be too much.  The "feature" can be anything, not just a mode
setting. Also, you will have fbdev drivers writing their own ioctls just
for these "little" features, and each will need to have its own utility
written specifically for the driver.  If you have an
fb_var_screeninfo.tweaks field, you can simply use fbset, and it can be
used for all drivers.  One can even collect all possible 'hardware'
tweaks and create a general fb tweaks utility just by using fbset.

Of course, if the feature requires something more than just turning a
switch on and off, then an ioctl is more practical.

Tony



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: LCD scaling type

[Benjamin Herrenschmidt]

On Sat, 2003-01-11 at 12:35, Antonino Daplas wrote:
> If you only need to do is turn something on or off, assigning it an
> ioctl may be too much.  The "feature" can be anything, not just a mode
> setting. Also, you will have fbdev drivers writing their own ioctls just
> for these "little" features, and each will need to have its own utility
> written specifically for the driver.  If you have an
> fb_var_screeninfo.tweaks field, you can simply use fbset, and it can be
> used for all drivers.  One can even collect all possible 'hardware'
> tweaks and create a general fb tweaks utility just by using fbset.
> 
> Of course, if the feature requires something more than just turning a
> switch on and off, then an ioctl is more practical.

Hrm... I think this is going too far for var_screeninfo. However,
we do have need for such "tunable" settings, that can be
brightness/contrast/backlight kind of stuff, geometry on some i2c-driven
monitors (iMacs typically) etc...

It may be interesting to think about an API where the fbdev (or the
monitor layer, which is something we currently lack that should probably
sit on top of fbdev) to expose the available "settings" and have std
ioctls to get/set their values. A bit like sound mixer settings work
today maybe.

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).
 

-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: LCD scaling type

[Antonino Daplas]

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

Re: LCD scaling type

[Antonino Daplas]

On Sat, 2003-01-11 at 21:29, Geert Uytterhoeven wrote:
> On 11 Jan 2003, Antonino Daplas wrote:
> > 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.
> 
> Since directcolor is a superset of truecolor, shouldn't a driver always use
> directcolor, if the hardware supports it?
> 
Some apps don't know how to treat directcolor.  DirectFB-0.9.15 is
messed up when visual is in directcolor, so I need truecolor here. I
submitted a patch to them so it should get fixed with their next
release.

However, when I go to X, I want it to be in directcolor, for gamma
utilities to work 

Tony




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: LCD scaling type

[Geert Uytterhoeven]

On 11 Jan 2003, Antonino Daplas wrote:
> 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.

Since directcolor is a superset of truecolor, shouldn't a driver always use
directcolor, if the hardware supports it?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com