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.
