Hi Geert,

On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:

On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:

quoted

quoted

When will the driver report FB_{TYPE,VISUAL}_FOURCC?
  - When using a mode that cannot be represented in the legacy way,

Definitely.

quoted

  - But what with modes that can be represented? Legacy software cannot
    handle FB_{TYPE,VISUAL}_FOURCC.

My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called with a
non-FOURCC format, the driver will report non-FOURCC types and visuals.

Hmm, two use cases:
  - The video mode is configured using a FOURCC-aware tool ("fbset on
steroids").

Such as http://git.ideasonboard.org/?pûdev-test.git;a=summary :-)

    Later the user runs a legacy application.
      => Do not retain FOURCC across opening of /dev/fb*.

I know about that problem, but it's not that easy to work around. We have no 
per-open fixed and variable screen info, and FB devices can be opened by 
multiple applications at the same time.

  - Is there an easy way to force FOURCC reporting, so new apps don't have
to support parsing the legacy formats? This is useful for new apps that
want to support (a subset of) FOURCC modes only.

Not at the moment.

-- 
Regards,

Laurent Pinchart