Re: [PATCH 01/11] video: Add support for the Avionic Design Xanthos framebuffer.

[Thierry Reding <thierry.reding@avionic-design.de>]

* Krzysztof Helt wrote:
> On Mon, 18 May 2009 10:53:01 +0200
> Thierry Reding <thierry.reding@avionic-design.de> wrote:
[...]
> > > I have no comments to rest of the patch so I removed it.
> > > 
> > > I have a general comment that you should make your driver
> > > conform to the fbdev API (check_var/set_par) for mode setting.
> > > I know you have the scaler, so leave the adfxfb_ioctl to handle it.
> > > If you define the set_par/check_var functions to handle size of
> > > the overlay's input (without scaling) and color format one can
> > > use standard FBIOPUT_VSCREENINFO and 
> > > FBIOGET_VSCREENINFO ioctls to set and read your overlay.
> > > If the overlay should be scaled use the custom ioctls to set the 
> > > scaling factors only.
> > > Currently, your driver looks like it wants to work around the
> > > fbdev API. See the skeletonfb.c for guidance.
> > 
> > I was under the impression that FBIOPUT_SCREENINFO was used to set the
> > framebuffer resolution, which can be (even usually is) different from
> > that of the overlay. How can I distinguish between which of the video
> > pages (framebuffer or overlay) should be modified?
> > 
> 
> The FBIOPUT_SCREENINFO is used for the framebuffer and not the overlay.
> I got an impression that your framebuffer has a scaler and can be scaled to
> display resolution without changing framebuffer resolution.

It is possible to use the scaler for that purpose, but we've never done (or
needed) that. The framebuffer always runs at the native resolution (the
processor board is tightly coupled to the rest of the hardware, including
display). The scaler is only used to take arbitrary-sized images and resize
them to another arbitrary size for display in the overlay (used for video
playback, for instance).

> How do you program framebuffer registers? Usually, there is a set_par()
> function to do this. If you have a framebuffer that cannot change a resolution
> (either fixed resolution framebuffer or with resolution which can be set only
> during board set up) do not define fb_check_var() or check there if the mode
> has not changed.

The framebuffer can actually change the resolution, though we've never tried
that in practice. Each derived board comes with a default predefined
resolution that is never changed (because the displays we use don't support
mode setting either). Therefore changing the resolution does not make sense.
I guess it is better, as you say, to not define fb_check_var() in this case
until at some point it may become relevant.

> Regards,
> Krzysztof

Thierry


------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects