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

[Dave Airlie]

On Sat, Apr 23, 2011 at 6:17 AM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> 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).


Was going to put them in -next as soon as I open it, its holidays I
for one won't be doing squat until next Wednesday.

Dave.