Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API

[Geert Uytterhoeven <geert@linux-m68k.org>]

On Fri, Jun 24, 2011 at 08:19, Paul Mundt <lethal@linux-sh.org> wrote:
> On Thu, Jun 23, 2011 at 06:08:03PM +0200, Geert Uytterhoeven wrote:
>> On Wed, Jun 22, 2011 at 07:45, Florian Tobias Schandinat
>> <FlorianSchandinat@gmx.de> wrote:
>> > On 06/21/2011 10:31 PM, Laurent Pinchart wrote:
>> >> On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote:
>> >>> 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