On Mon, Aug 29, 2011 at 13:08, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > On Monday 29 August 2011 13:04:15 Geert Uytterhoeven wrote: >> On Mon, Aug 29, 2011 at 12:09, Laurent Pinchart wrote: >> > On Monday 29 August 2011 11:36:07 Geert Uytterhoeven wrote: >> >> On Mon, Aug 29, 2011 at 10:50, Laurent Pinchart wrote: >> [...] >> >> > If my understanding is now correct, a V4L2 planar YUV type where Y, U and >> > V components are stored in separate byte-oriented planes, with each >> > plane storing Y, U or V components packed (such as >> > http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html), >> > would be of neither FB_TYPE_PLANES nor FB_TYPE_PACKED. The same would be >> > true for an RGB format where each component is stored in a separate >> > plane with each plane sotring R, G or B packed. >> >> Indeed. Currently this cannot be represented. > > Good, at least I now understand the situation :-) > >> For ideas from the past, see e.g. >> http://comments.gmane.org/gmane.linux.fbdev.devel/10951. >> >> > If the above is correct, what FB_TYPE_* should a driver report when using >> > FB_VISUAL_FOURCC with V4L2_PIX_FMT_YUV422P >> > (http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html) >> > or V4L2_PIX_FMT_NV12 >> > (http://linuxtv.org/downloads/v4l-dvb-apis/re25.html) for instance ? >> >> We need new types for those. Or always use FOURCC for them. > > My proposal currently defined FB_VISUAL_FOURCC. What about adding > FB_TYPE_FOURCC as well ? That may make sense. When will the driver report FB_{TYPE,VISUAL}_FOURCC? - When using a mode that cannot be represented in the legacy way, - But what with modes that can be represented? Legacy software cannot handle FB_{TYPE,VISUAL}_FOURCC. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx 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-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
