On Fri, Jun 24, 2011 at 08:19, Paul Mundt [off-list ref] wrote:

On Thu, Jun 23, 2011 at 06:08:03PM +0200, Geert Uytterhoeven wrote:

quoted

On Wed, Jun 22, 2011 at 07:45, Florian Tobias Schandinat
[off-list ref] wrote:

quoted

On 06/21/2011 10:31 PM, Laurent Pinchart wrote:

quoted

On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote:

quoted

As FOURCC values are always 4 ASCII characters (hence all 4 bytes must
be non-zero), I don't think there are any conflicts with existing values
of
nonstd. To make it even safer and easier to parse, you could set bit 31
of
nonstd as a FOURCC indicator.

I would then create a union between nonstd and fourcc, and document nonstd
as
being used for the legacy API only. Most existing drivers use a couple of
nonstd bits only. The driver that (ab)uses nonstd the most is pxafb and
uses
bits 22:0. Bits 31:24 are never used as far as I can tell, so nonstd&
0xff000000 != 0 could be used as a FOURCC mode test.

This assumes that FOURCCs will never have their last character set to
'\0'. Is
that a safe assumption for the future ?

Yes, I think. The information I found indicates that space should be used
for padding, so a \0 shouldn't exist.
I think using only the nonstd field and requiring applications to check the
capabilities would be possible, although not fool proof ;)

So we can declare the 8 msb bits of nonstd reserved, and assume FOURCC if
any of them is set.

Nicely backwards compatible, as sane drivers should reject nonstd values they
don't support (apps _will_ start filling in FOURCC values ignoring capabilities,
won't they?).

That seems like a reasonable case, but if we're going to do that then
certainly the nonstd bit encoding needs to be documented and treated as a
hard ABI.

I'm not so sure about the if any bit in the upper byte is set assume
FOURCC case though, there will presumably be other users in the future
that will want bits for themselves, too. What exactly was the issue with
having a FOURCC capability bit in the upper byte?

That indeed gives less issues (as long as you don't stuff 8-bit ASCII
in the MSB)
and more bits for tradiditional nonstd users.

BTW, after giving it some more thought: what does the FB_CAP_FOURCC buys
us? It's not like all drivers will support whatever random FOURCC mode
you give them,
so you have to check whether it's supported by doing a set_var first.

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