Hi Geert,

On Monday 29 August 2011 16:26:02 Geert Uytterhoeven wrote:

On Mon, Aug 29, 2011 at 16:17, Laurent Pinchart wrote:

quoted

On Monday 29 August 2011 16:14:38 Geert Uytterhoeven wrote:

quoted

On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart wrote:

quoted

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

quoted

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

Yep.

quoted

quoted

    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.

quoted

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

So perhaps we do need new ioctls instead...
That would also ease an in-kernel translation layer.

Do you mean new ioctls to replace the FOURCC API proposal, or new ioctls
for the above two operations ?

New ioctls to replace the FOURCC proposal.

*sigh*...

I'd like other people's opinion on this before throwing everything away. 
Florian, Magnus, Guennadi, others, what do you think ?

-- 
Regards,

Laurent Pinchart