On Sat, Apr 23, 2011 at 6:17 AM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote:
> On Sat, 16 Apr 2011 06:42:44 +1000
> Dave Airlie <airlied@xxxxxxxxx> wrote:
>
>> On Sat, Apr 16, 2011 at 6:39 AM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote:
>> > On Sat, 16 Apr 2011 06:10:07 +1000
>> > Dave Airlie <airlied@xxxxxxxxx> 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.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
