All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: drm pixel formats update
Date: Wed, 16 Nov 2011 23:19:38 +0200	[thread overview]
Message-ID: <20111116211938.GO3477@intel.com> (raw)
In-Reply-To: <20111116195412.33f365ee@lxorguk.ukuu.org.uk>

On Wed, Nov 16, 2011 at 07:54:12PM +0000, Alan Cox wrote:
> > If anyone has problems with the way the formats are defined, please
> > speak up now! Since only Jesse has bothered to comment on my rantings
> > I can only assume people are happy with my approach to things.
> 
> Umm .. no. I don't see why they are needed. Its just an extra layer of
> gratuitious confusing indirection. The rest of the world speaks and
> understands FourCC sp for all the formats covered by an existing FourCC
> name we should just the existing name.
> 
> You might need to check one now and then but everyone doing video
> processing is familiar with them including all the Windows folk.

I think the only format in my list where I didn't use an existing fourcc
is I420/IYUV. And BTW, for that one I used the same "fake" fourcc that
v4l2 uses (YU12). 

And that brings another matter to the table. How should we deal with
duplicate fourccs? I420/IYUV and YUY2/YUYV come to mind.

Also, if I now add these ad-hoc fourccs for the RGB formats, and some
time later someone comes in with a format with a conflicting official
fourcc, what should we do?

Oh and one extra detail just occured to me regarding the three plane
formats. Should we even define formats for both the YUV vs. YVU
variant. Seeing as we now have independent handles and offsets for
each plane, we can make do with just one format definition.

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2011-11-16 21:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-16 18:42 drm pixel formats update ville.syrjala
2011-11-16 18:42 ` [PATCH 1/2] drm: Add a missing ')' ville.syrjala
2011-11-16 18:42 ` [PATCH 2/2] drm: Redefine pixel formats ville.syrjala
2011-11-16 19:16   ` Ilyes Gouta
2011-11-16 22:28     ` Ville Syrjälä
2011-11-17  7:52   ` Michel Dänzer
2011-11-17 13:06     ` Ville Syrjälä
2011-11-17 14:00       ` Michel Dänzer
2011-11-17 14:40         ` Ville Syrjälä
2011-11-16 19:13 ` drm pixel formats update James Simmons
2011-11-16 19:54 ` Alan Cox
2011-11-16 21:19   ` Ville Syrjälä [this message]
2011-11-16 21:23     ` Jesse Barnes
2011-11-16 22:20       ` Ville Syrjälä
2011-11-17 17:06         ` Jesse Barnes
2011-11-17 21:05           ` Rob Clark
2011-11-16 21:26     ` Alan Cox
2011-11-16 22:16       ` Ville Syrjälä
2011-11-29 12:10 ` Laurent Pinchart
2011-11-29 12:10   ` Laurent Pinchart
2011-11-29 13:30   ` Hans Verkuil
2011-11-29 13:30     ` Hans Verkuil
2011-11-29 16:13   ` Tomi Valkeinen
2011-11-29 16:13     ` Tomi Valkeinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111116211938.GO3477@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.