[PATCH 2/2] drm: parse color format support for digital displays

[Jesse Barnes]

On Sat, 16 Apr 2011 06:42:44 +1000
Dave Airlie <airlied at gmail.com> wrote:

> On Sat, Apr 16, 2011 at 6:39 AM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> > On Sat, 16 Apr 2011 06:10:07 +1000
> > Dave Airlie <airlied at gmail.com> wrote:
> >
> >> > -
> >> > +#define DRM_COLOR_FORMAT_RGB444                (1<<0)
> >> > +#define DRM_COLOR_FORMAT_YCRCB444      (1<<1)
> >> > +#define DRM_COLOR_FORMAT_YCRCB422      (1<<2)
> >> >  /*
> >> >  * Describes a given display (e.g. CRT or flat panel) and its limitations.
> >> >  */
> >> > @@ -201,6 +203,7 @@ struct drm_display_info {
> >> >        unsigned int bpc;
> >> >
> >> >        enum subpixel_order subpixel_order;
> >> > +       unsigned long color_formats;
> >>
> >> ^ wtf?
> >>
> >> unsigned long? its 2011.
> >
> > That doesn't tell me much about what you'd prefer...  I figured a
> > bitfield would be fairly extensible if new surface formats were added.
> > Maybe you're thinking it's not enough to support all the misc ones out
> > there though?
> 
> Its unsigned long, its a different size on 32 and 64-bit, not
> something I want to fall
> over when you add the 33rd bit field.

Ok, I sent an update for this one.  Also note that all these are kernel
internal structures, so we can change the format field to an array or
something later if we want to...

Any other changes you'd like?  Or do the patches look ok now (though I
probably should have made the subject drm/edid rather than just drm).

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center