On Sat, Nov 23, 2013 at 2:10 AM, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > On Fri, Nov 22, 2013 at 03:43:13PM -0800, Keith Packard wrote: >> Ville Syrjälä <ville.syrj...@linux.intel.com> writes: >> >> > What is this format anyway? -ENODOCS >> >> Same as MESA_FORMAT_SARGB8 and __DRI_IMAGE_FORMAT_SARGB8 :-) >> >> > If its just an srgb version of ARGB8888, then I wouldn't really want it >> > in drm_fourcc.h. I expect colorspacy stuff will be handled by various >> > crtc/plane properties in the kernel so we don't need to encode that >> > stuff into the fb format. >> >> It's not any different from splitting YUV codes from RGB codes; > > Not really. Saying something is YUV (or rather Y'CbCr) doesn't > actually tell you the color space. It just tells you whether the > information is encoded as R+G+B or Y+Cb+Cr. How you convert between > them is another matter. You need to know the gamma, color primaries, > chroma siting for sub-sampled YCbCr formats, etc.
Yep. Fbdev has a separation of type (how pixel values are laid out in memory), fb_bitfield structs (how tuples are formed into pixels), and visual (how to interprete the tuples). The fb_bitfield structs do have RGB-centric names, but you could use them for e.g. Y, Cb, Cr, and alpha, giving a proper visual. Unfortunately the YCbCr visuals haven't made it into mainline. FOURCC unifies all of that in (not so) unique 32-bit IDs. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html