From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rhee, C. Joon" Subject: YUV Framebuffer Date: Tue, 16 Oct 2007 17:00:51 -0700 Message-ID: <27AAC353AE72C840926448157F375E72012B59B1@NAEX17.na.qualcomm.com> Reply-To: linux-fbdev-devel@lists.sourceforge.net Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0005782193==" Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1IhwLM-0000iL-KN for linux-fbdev-devel@lists.sourceforge.net; Tue, 16 Oct 2007 17:01:00 -0700 Received: from ithilien.qualcomm.com ([129.46.51.59]) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1IhwLM-00066e-BK for linux-fbdev-devel@lists.sourceforge.net; Tue, 16 Oct 2007 17:01:00 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9H00rKK020307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 Oct 2007 17:00:54 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9H00m6I013142 for ; Tue, 16 Oct 2007 17:00:53 -0700 (PDT) Content-class: urn:content-classes:message List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-fbdev-devel-bounces@lists.sourceforge.net Errors-To: linux-fbdev-devel-bounces@lists.sourceforge.net To: linux-fbdev-devel@lists.sourceforge.net This is a multi-part message in MIME format. --===============0005782193== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81050.C84115D4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81050.C84115D4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is it possible to create framebuffer color format in YUV (eg. YUV422 interleaved) and expose it through /dev/fb? What would be fb_info type? =20 And how about about fb_var_screeninfo.green/blue/red offset?=20 =20 Joon ------_=_NextPart_001_01C81050.C84115D4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is it = possible to create framebuffer color format in YUV (eg. YUV422 interleaved) and = expose it through /dev/fb?

What would be = fb_info type?

And how about = about fb_var_screeninfo.green/blue/red offset?

Joon

------_=_NextPart_001_01C81050.C84115D4-- --===============0005782193== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ --===============0005782193== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Linux-fbdev-devel mailing list Linux-fbdev-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel --===============0005782193==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: YUV Framebuffer Date: Wed, 17 Oct 2007 08:57:32 +0200 (CEST) Message-ID: References: <27AAC353AE72C840926448157F375E72012B59B1@NAEX17.na.qualcomm.com> Reply-To: linux-fbdev-devel@lists.sourceforge.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1Ii2qW-0005SK-Ls for linux-fbdev-devel@lists.sourceforge.net; Tue, 16 Oct 2007 23:57:38 -0700 Received: from hoboe1bl1.telenet-ops.be ([195.130.137.72]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1Ii2qV-0006mS-AQ for linux-fbdev-devel@lists.sourceforge.net; Tue, 16 Oct 2007 23:57:36 -0700 In-Reply-To: <27AAC353AE72C840926448157F375E72012B59B1@NAEX17.na.qualcomm.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-fbdev-devel-bounces@lists.sourceforge.net Errors-To: linux-fbdev-devel-bounces@lists.sourceforge.net To: "Rhee, C. Joon" Cc: Linux Frame Buffer Device Development On Tue, 16 Oct 2007, Rhee, C. Joon wrote: > Is it possible to create framebuffer color format in YUV (eg. YUV422 > interleaved) and expose it through /dev/fb? > > What would be fb_info type? What do you mean with `interleaved'? Even and odd frames are separate (interlace)? For YUV422, you have to add a new visual type. A long time ago, I used this for a non-public test project: #define FB_TYPE_PACKED_PIXELS_LACED 5 /* Interlaced Packed Pixels */ #define FB_TYPE_PACKED_PIXELS_4AREAS 6 /* 4 areas of Packed Pixels */ #define FB_VISUAL_YCBCR422 6 /* YCbCr 4:2:2 */ #define FB_VISUAL_YCBCR420 7 /* YCbCr 4:2:0 */ > And how about about fb_var_screeninfo.green/blue/red offset? Just assume red, green, and blue mean Y, U, and V? 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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rhee, C. Joon" Subject: Re: YUV Framebuffer Date: Wed, 17 Oct 2007 10:07:55 -0700 Message-ID: <27AAC353AE72C840926448157F375E72012B5A8F@NAEX17.na.qualcomm.com> References: <27AAC353AE72C840926448157F375E72012B59B1@NAEX17.na.qualcomm.com> Reply-To: linux-fbdev-devel@lists.sourceforge.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1IiCR1-00047F-3S for linux-fbdev-devel@lists.sourceforge.net; Wed, 17 Oct 2007 10:11:55 -0700 Received: from ithilien.qualcomm.com ([129.46.51.59]) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1IiCNP-00079M-IS for linux-fbdev-devel@lists.sourceforge.net; Wed, 17 Oct 2007 10:08:12 -0700 Content-class: urn:content-classes:message In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-fbdev-devel-bounces@lists.sourceforge.net Errors-To: linux-fbdev-devel-bounces@lists.sourceforge.net To: geert@linux-m68k.org Cc: Linux Frame Buffer Device Development Hi, Interleaved means YCBCR is on the same plane in this order. Y CB Y CR Y CB Y CR.... (TV-Out) The problem of matching Y=G, CB=B and CR=R for RGB offset is that the pixel cannot be represented directly since CB/CR gets shared between Ys. So, bitsperpixel would be 16 bit and both B and R offset will be 8. Joon -----Original Message----- From: geert@linux-m68k.org [mailto:geert@linux-m68k.org] Sent: Tuesday, October 16, 2007 11:58 PM To: Rhee, C. Joon Cc: Linux Frame Buffer Device Development Subject: Re: [Linux-fbdev-devel] YUV Framebuffer On Tue, 16 Oct 2007, Rhee, C. Joon wrote: > Is it possible to create framebuffer color format in YUV (eg. YUV422 > interleaved) and expose it through /dev/fb? > > What would be fb_info type? What do you mean with `interleaved'? Even and odd frames are separate (interlace)? For YUV422, you have to add a new visual type. A long time ago, I used this for a non-public test project: #define FB_TYPE_PACKED_PIXELS_LACED 5 /* Interlaced Packed Pixels */ #define FB_TYPE_PACKED_PIXELS_4AREAS 6 /* 4 areas of Packed Pixels */ #define FB_VISUAL_YCBCR422 6 /* YCbCr 4:2:2 */ #define FB_VISUAL_YCBCR420 7 /* YCbCr 4:2:0 */ > And how about about fb_var_screeninfo.green/blue/red offset? Just assume red, green, and blue mean Y, U, and V? 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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: YUV Framebuffer Date: Wed, 17 Oct 2007 21:45:05 +0200 (CEST) Message-ID: References: <27AAC353AE72C840926448157F375E72012B59B1@NAEX17.na.qualcomm.com> <27AAC353AE72C840926448157F375E72012B5A8F@NAEX17.na.qualcomm.com> Reply-To: linux-fbdev-devel@lists.sourceforge.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1IiEpL-00030z-Qy for linux-fbdev-devel@lists.sourceforge.net; Wed, 17 Oct 2007 12:45:11 -0700 Received: from ananke.telenet-ops.be ([195.130.137.78]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1IiEpJ-00028Q-FH for linux-fbdev-devel@lists.sourceforge.net; Wed, 17 Oct 2007 12:45:11 -0700 In-Reply-To: <27AAC353AE72C840926448157F375E72012B5A8F@NAEX17.na.qualcomm.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-fbdev-devel-bounces@lists.sourceforge.net Errors-To: linux-fbdev-devel-bounces@lists.sourceforge.net To: "Rhee, C. Joon" Cc: Linux Frame Buffer Device Development On Wed, 17 Oct 2007, Rhee, C. Joon wrote: > Interleaved means YCBCR is on the same plane in this order. > Y CB Y CR Y CB Y CR.... (TV-Out) So it's still FB_TYPE_PACKED_PIXELS. > The problem of matching Y=G, CB=B and CR=R for RGB offset is that the > pixel cannot be represented directly since CB/CR gets shared between Ys. > > So, bitsperpixel would be 16 bit and both B and R offset will be 8. Doesn't sound that bad to me, if you introduce a FB_VISUAL_YCBYCR visual. Even pixels have a Cb, odd have a Cr component. The alternative is to sets bits_per_pixel = 32, but then you get more illogical component offsets. Anyone with a better suggestion? > -----Original Message----- > From: geert@linux-m68k.org [mailto:geert@linux-m68k.org] > Sent: Tuesday, October 16, 2007 11:58 PM > To: Rhee, C. Joon > Cc: Linux Frame Buffer Device Development > Subject: Re: [Linux-fbdev-devel] YUV Framebuffer > > On Tue, 16 Oct 2007, Rhee, C. Joon wrote: > > Is it possible to create framebuffer color format in YUV (eg. YUV422 > > interleaved) and expose it through /dev/fb? > > > > What would be fb_info type? > > What do you mean with `interleaved'? > Even and odd frames are separate (interlace)? > > For YUV422, you have to add a new visual type. > > A long time ago, I used this for a non-public test project: > > #define FB_TYPE_PACKED_PIXELS_LACED 5 /* Interlaced Packed > Pixels */ > #define FB_TYPE_PACKED_PIXELS_4AREAS 6 /* 4 areas of Packed > Pixels */ > > #define FB_VISUAL_YCBCR422 6 /* YCbCr 4:2:2 */ > #define FB_VISUAL_YCBCR420 7 /* YCbCr 4:2:0 */ > > > And how about about fb_var_screeninfo.green/blue/red offset? > > Just assume red, green, and blue mean Y, U, and V? 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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Antonino A. Daplas" Subject: Re: YUV Framebuffer Date: Thu, 18 Oct 2007 21:20:10 +0800 Message-ID: <1192713610.8484.53.camel@daplas> References: <27AAC353AE72C840926448157F375E72012B59B1@NAEX17.na.qualcomm.com> <27AAC353AE72C840926448157F375E72012B5A8F@NAEX17.na.qualcomm.com> Reply-To: linux-fbdev-devel@lists.sourceforge.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1IiVIe-0003U2-6x for linux-fbdev-devel@lists.sourceforge.net; Thu, 18 Oct 2007 06:20:32 -0700 Received: from wx-out-0506.google.com ([66.249.82.227]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1IiVIc-0000IF-GU for linux-fbdev-devel@lists.sourceforge.net; Thu, 18 Oct 2007 06:20:32 -0700 Received: by wx-out-0506.google.com with SMTP id h31so165774wxd for ; Thu, 18 Oct 2007 06:20:29 -0700 (PDT) In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-fbdev-devel-bounces@lists.sourceforge.net Errors-To: linux-fbdev-devel-bounces@lists.sourceforge.net To: linux-fbdev-devel@lists.sourceforge.net Cc: "Rhee, C. Joon" , "Geert.Uytterhoeven" On Wed, 2007-10-17 at 21:45 +0200, Geert Uytterhoeven wrote: > On Wed, 17 Oct 2007, Rhee, C. Joon wrote: > > Interleaved means YCBCR is on the same plane in this order. > > Y CB Y CR Y CB Y CR.... (TV-Out) > > So it's still FB_TYPE_PACKED_PIXELS. > > > The problem of matching Y=G, CB=B and CR=R for RGB offset is that the > > pixel cannot be represented directly since CB/CR gets shared between Ys. > > > > So, bitsperpixel would be 16 bit and both B and R offset will be 8. > > Doesn't sound that bad to me, if you introduce a FB_VISUAL_YCBYCR > visual. Even pixels have a Cb, odd have a Cr component. We need at least 3 fields to describe YUV. 1. The component size - fb_bitfield.length 2. The sample period - fb_bitfield.offset 3. The component ordering - fb_bitfield.msb_right So if Y = red, U = green, V = blue YUV422 red|green|blue.length = 8 /* 8 bits per component */ red.offset = 1 /* sampled every pixel */ green.offset = blue.offset = 2 /* sampled every 2 pixels */ red.msb_right = 1, green.msb_right = 2, blue.msb_right = 3 (Y U V order) UVY411 red|green|blue.length = 8; red.offset = 1; green.offset = blue.offset = 4; red.msb_right = 3, green.msb_right = 2, blue.msb_right = 1; The FB_VISUAL_* will differentiate if the bitfields are interpreted as RGB or YUV. That's the only way I can think of describing YUV packed pixel formats without adding new fields, or modifying our user-visible structures. We will need separate drawing functions for fbcon's use. Of course, the simplest way is to use fourcc naming for our FB_VISUAL_* constants. But that will become too unwieldy over time. Tony ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: YUV Framebuffer Date: Thu, 18 Oct 2007 15:41:53 +0200 (CEST) Message-ID: References: <27AAC353AE72C840926448157F375E72012B59B1@NAEX17.na.qualcomm.com> <27AAC353AE72C840926448157F375E72012B5A8F@NAEX17.na.qualcomm.com> <1192713610.8484.53.camel@daplas> Reply-To: linux-fbdev-devel@lists.sourceforge.net Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-584337861-576117726-1192714913=:20173" Return-path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1IiVdW-0005j7-MW for linux-fbdev-devel@lists.sourceforge.net; Thu, 18 Oct 2007 06:42:06 -0700 Received: from vervifontaine.sonytel.be ([80.88.33.193] helo=vervifontaine.sonycom.com) by mail.sourceforge.net with esmtp (Exim 4.44) id 1IiVdU-0000iv-QJ for linux-fbdev-devel@lists.sourceforge.net; Thu, 18 Oct 2007 06:42:06 -0700 In-Reply-To: <1192713610.8484.53.camel@daplas> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-fbdev-devel-bounces@lists.sourceforge.net Errors-To: linux-fbdev-devel-bounces@lists.sourceforge.net To: "Antonino A. Daplas" Cc: "Rhee, C. Joon" , linux-fbdev-devel@lists.sourceforge.net This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---584337861-576117726-1192714913=:20173 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 18 Oct 2007, Antonino A. Daplas wrote: > On Wed, 2007-10-17 at 21:45 +0200, Geert Uytterhoeven wrote: > > On Wed, 17 Oct 2007, Rhee, C. Joon wrote: > > > Interleaved means YCBCR is on the same plane in this order. > > > Y CB Y CR Y CB Y CR.... (TV-Out) > >=20 > > So it's still FB_TYPE_PACKED_PIXELS. > >=20 > > > The problem of matching Y=3DG, CB=3DB and CR=3DR for RGB offset is = that the > > > pixel cannot be represented directly since CB/CR gets shared betwee= n Ys. > > >=20 > > > So, bitsperpixel would be 16 bit and both B and R offset will be 8. > >=20 > > Doesn't sound that bad to me, if you introduce a FB_VISUAL_YCBYCR > > visual. Even pixels have a Cb, odd have a Cr component. >=20 > We need at least 3 fields to describe YUV. >=20 > 1. The component size - fb_bitfield.length > 2. The sample period - fb_bitfield.offset > 3. The component ordering - fb_bitfield.msb_right This completely changes the meaning of the latter 2 fields... > So if Y =3D red, U =3D green, V =3D blue >=20 > YUV422 >=20 > red|green|blue.length =3D 8 /* 8 bits per component */ > red.offset =3D 1 /* sampled every pixel */ > green.offset =3D blue.offset =3D 2 /* sampled every 2 pixels */ > red.msb_right =3D 1, green.msb_right =3D 2, blue.msb_right =3D 3 > (Y U V order) >=20 > UVY411 >=20 > red|green|blue.length =3D 8; > red.offset =3D 1; > green.offset =3D blue.offset =3D 4; > red.msb_right =3D 3, green.msb_right =3D 2, blue.msb_right =3D 1; And you would use bits_per_pixel =3D 8, as you no longer have access to t= he fb_bitfield.offsets (in the sense of `offsets within a pixel')? How would you express YUV420? Alternatively: - YUV422 really is 16 bits per pixel. - YUV411 and YUV420 really are 12 bits per pixel. But I don't think this makes things easier, especially not for the 12 bpp variants. > The FB_VISUAL_* will differentiate if the bitfields are interpreted as > RGB or YUV. >=20 > That's the only way I can think of describing YUV packed pixel formats > without adding new fields, or modifying our user-visible structures. >=20 > We will need separate drawing functions for fbcon's use. Of course. > Of course, the simplest way is to use fourcc naming for our FB_VISUAL_* > constants. But that will become too unwieldy over time. With kind regards, =20 Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village =C2=B7 Da Vincilaan 7-D1 =C2=B7 B-1935 Zaventem =C2= =B7 Belgium =20 Phone: +32 (0)2 700 8453=09 Fax: +32 (0)2 700 8622=09 E-mail: Geert.Uytterhoeven@sonycom.com=09 Internet: http://www.sony-europe.com/ =09 Sony Network and Software Technology Center Europe=09 A division of Sony Service Centre (Europe) N.V.=09 Registered office: Technologielaan 7 =C2=B7 B-1840 Londerzeel =C2=B7 Belg= ium=09 VAT BE 0413.825.160 =C2=B7 RPR Brussels=09 Fortis Bank Zaventem =C2=B7 Swift GEBABEBB08A =C2=B7 IBAN BE3900138235861= 9 ---584337861-576117726-1192714913=:20173 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ---584337861-576117726-1192714913=:20173 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Linux-fbdev-devel mailing list Linux-fbdev-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel ---584337861-576117726-1192714913=:20173-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Antonino A. Daplas" Subject: Re: YUV Framebuffer Date: Fri, 19 Oct 2007 07:03:34 +0800 Message-ID: <1192748614.5089.8.camel@daplas> References: <27AAC353AE72C840926448157F375E72012B59B1@NAEX17.na.qualcomm.com> <27AAC353AE72C840926448157F375E72012B5A8F@NAEX17.na.qualcomm.com> <1192713610.8484.53.camel@daplas> Reply-To: linux-fbdev-devel@lists.sourceforge.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1IiePS-000751-Ec for linux-fbdev-devel@lists.sourceforge.net; Thu, 18 Oct 2007 16:04:10 -0700 Received: from hs-out-0708.google.com ([64.233.178.241] helo=hs-out-2021.google.com) by mail.sourceforge.net with esmtp (Exim 4.44) id 1IiePP-0007ey-NC for linux-fbdev-devel@lists.sourceforge.net; Thu, 18 Oct 2007 16:04:10 -0700 Received: by hs-out-2021.google.com with SMTP id 55so244056hsc for ; Thu, 18 Oct 2007 16:04:07 -0700 (PDT) In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-fbdev-devel-bounces@lists.sourceforge.net Errors-To: linux-fbdev-devel-bounces@lists.sourceforge.net To: Geert Uytterhoeven Cc: "Rhee, C. Joon" , linux-fbdev-devel@lists.sourceforge.net On Thu, 2007-10-18 at 15:41 +0200, Geert Uytterhoeven wrote: > On Thu, 18 Oct 2007, Antonino A. Daplas wrote: > > On Wed, 2007-10-17 at 21:45 +0200, Geert Uytterhoeven wrote: > > > On Wed, 17 Oct 2007, Rhee, C. Joon wrote: > > > > Interleaved means YCBCR is on the same plane in this order. > > > > Y CB Y CR Y CB Y CR.... (TV-Out) > > > > > > So it's still FB_TYPE_PACKED_PIXELS. > > > > > > > The problem of matching Y=G, CB=B and CR=R for RGB offset is that the > > > > pixel cannot be represented directly since CB/CR gets shared between Ys. > > > > > > > > So, bitsperpixel would be 16 bit and both B and R offset will be 8. > > > > > > Doesn't sound that bad to me, if you introduce a FB_VISUAL_YCBYCR > > > visual. Even pixels have a Cb, odd have a Cr component. > > > > We need at least 3 fields to describe YUV. > > > > 1. The component size - fb_bitfield.length > > 2. The sample period - fb_bitfield.offset > > 3. The component ordering - fb_bitfield.msb_right > > This completely changes the meaning of the latter 2 fields... > Yes, the intent was to reuse the already present fields to express YUV formats. > > So if Y = red, U = green, V = blue > > > > YUV422 > > > > red|green|blue.length = 8 /* 8 bits per component */ > > red.offset = 1 /* sampled every pixel */ > > green.offset = blue.offset = 2 /* sampled every 2 pixels */ > > red.msb_right = 1, green.msb_right = 2, blue.msb_right = 3 > > (Y U V order) > > > > UVY411 > > > > red|green|blue.length = 8; > > red.offset = 1; > > green.offset = blue.offset = 4; > > red.msb_right = 3, green.msb_right = 2, blue.msb_right = 1; > > And you would use bits_per_pixel = 8, as you no longer have access to the > fb_bitfield.offsets (in the sense of `offsets within a pixel')? We can define the bits_per_pixel as the effective pixel size. For 422, that would be 16. For 411, that would be 12. > > How would you express YUV420? We can't. We need another set of fields in the vertical axis. > > Alternatively: > - YUV422 really is 16 bits per pixel. > - YUV411 and YUV420 really are 12 bits per pixel. > But I don't think this makes things easier, especially not for the 12 bpp > variants. > > > The FB_VISUAL_* will differentiate if the bitfields are interpreted as > > RGB or YUV. > > > > That's the only way I can think of describing YUV packed pixel formats > > without adding new fields, or modifying our user-visible structures. > > > > We will need separate drawing functions for fbcon's use. > > Of course. Basically, since most YUV formats are fundamentally different from RGB (where all components are sampled per pixel), our best bet is to revive the framebuffer overlay support that was proposed several years ago. Or, if we do not want this in the kernel, we can always tell them to use the DirectFB library instead. What do you think? Should we extend the fb system to support YUV formats? Tony ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: YUV Framebuffer Date: Fri, 19 Oct 2007 09:13:49 +0200 (CEST) Message-ID: References: <27AAC353AE72C840926448157F375E72012B59B1@NAEX17.na.qualcomm.com> <27AAC353AE72C840926448157F375E72012B5A8F@NAEX17.na.qualcomm.com> <1192713610.8484.53.camel@daplas> <1192748614.5089.8.camel@daplas> Reply-To: linux-fbdev-devel@lists.sourceforge.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1Iim3O-0001FR-Qc for linux-fbdev-devel@lists.sourceforge.net; Fri, 19 Oct 2007 00:13:54 -0700 Received: from astra.telenet-ops.be ([195.130.132.58]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1Iim3O-0001AL-32 for linux-fbdev-devel@lists.sourceforge.net; Fri, 19 Oct 2007 00:13:54 -0700 In-Reply-To: <1192748614.5089.8.camel@daplas> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-fbdev-devel-bounces@lists.sourceforge.net Errors-To: linux-fbdev-devel-bounces@lists.sourceforge.net To: linux-fbdev-devel@lists.sourceforge.net Cc: "Rhee, C. Joon" On Fri, 19 Oct 2007, Antonino A. Daplas wrote: > On Thu, 2007-10-18 at 15:41 +0200, Geert Uytterhoeven wrote: > > On Thu, 18 Oct 2007, Antonino A. Daplas wrote: > > > On Wed, 2007-10-17 at 21:45 +0200, Geert Uytterhoeven wrote: > > > > On Wed, 17 Oct 2007, Rhee, C. Joon wrote: > > > > > Interleaved means YCBCR is on the same plane in this order. > > > > > Y CB Y CR Y CB Y CR.... (TV-Out) > > > > > > > > So it's still FB_TYPE_PACKED_PIXELS. > > > > > > > > > The problem of matching Y=G, CB=B and CR=R for RGB offset is that the > > > > > pixel cannot be represented directly since CB/CR gets shared between Ys. > > > > > > > > > > So, bitsperpixel would be 16 bit and both B and R offset will be 8. > > > > > > > > Doesn't sound that bad to me, if you introduce a FB_VISUAL_YCBYCR > > > > visual. Even pixels have a Cb, odd have a Cr component. > > > > > > We need at least 3 fields to describe YUV. > > > > > > 1. The component size - fb_bitfield.length > > > 2. The sample period - fb_bitfield.offset > > > 3. The component ordering - fb_bitfield.msb_right > > > > This completely changes the meaning of the latter 2 fields... > > Yes, the intent was to reuse the already present fields to express YUV > formats. IC. > > > So if Y = red, U = green, V = blue > > > > > > YUV422 > > > > > > red|green|blue.length = 8 /* 8 bits per component */ > > > red.offset = 1 /* sampled every pixel */ > > > green.offset = blue.offset = 2 /* sampled every 2 pixels */ > > > red.msb_right = 1, green.msb_right = 2, blue.msb_right = 3 > > > (Y U V order) > > > > > > UVY411 > > > > > > red|green|blue.length = 8; > > > red.offset = 1; > > > green.offset = blue.offset = 4; > > > red.msb_right = 3, green.msb_right = 2, blue.msb_right = 1; > > > > And you would use bits_per_pixel = 8, as you no longer have access to the > > fb_bitfield.offsets (in the sense of `offsets within a pixel')? > > We can define the bits_per_pixel as the effective pixel size. For 422, > that would be 16. For 411, that would be 12. > > > How would you express YUV420? > > We can't. We need another set of fields in the vertical axis. > > > Alternatively: > > - YUV422 really is 16 bits per pixel. > > - YUV411 and YUV420 really are 12 bits per pixel. > > But I don't think this makes things easier, especially not for the 12 bpp > > variants. > > > > > The FB_VISUAL_* will differentiate if the bitfields are interpreted as > > > RGB or YUV. > > > > > > That's the only way I can think of describing YUV packed pixel formats > > > without adding new fields, or modifying our user-visible structures. > > > > > > We will need separate drawing functions for fbcon's use. > > > > Of course. > > Basically, since most YUV formats are fundamentally different from RGB > (where all components are sampled per pixel), our best bet is to revive > the framebuffer overlay support that was proposed several years ago. What with frame buffers where there's no overlay, i.e. the YUV buffer is the single frame buffer? > Or, if we do not want this in the kernel, we can always tell them to use > the DirectFB library instead. > > What do you think? Should we extend the fb system to support YUV > formats? It's definitely needed for single YUV frame buffers. What about: - fb_fix_screeninfo.visual = FB_VISUAL_YUV - fb_var_screeninfo.nonstd = FB_NONSTD_YUV - use an additional struct fb_yuv_screeninfo for the other parameters? or maybe better, put them in fb_var_screeninfo.reserved[]? 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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/