On Fri, Jan 30, 2015 at 9:35 AM, Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: > > On 01/30/2015 01:43 PM, Rob Clark wrote: >> >> On Fri, Jan 30, 2015 at 5:51 AM, Tvrtko Ursulin >> <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: >>>> >>>> +/* >>>> + * Format Modifier tokens: >>>> + * >>>> + * When adding a new token please document the layout with a code >>>> comment, >>>> + * similar to the fourcc codes above. drm_fourcc.h is considered the >>>> + * authoritative source for all of these. >>>> + */ >>> >>> >>> >>> On one side modifiers are supposed to be opaque, but then this suggest >>> they >>> are supposed to be added in this file and described. Is that right? >> >> >> >> correct.. opaque as in basically enum values. >> >> We do want a description of the format so when someone comes along and >> adds a new value, we have a chance of realizing that it is the same as >> an existing value, since there are cases where gpu's from different >> vendors can support (for example) the same tiling formats. > > > Opaque kind of suggests it is driver private and from that angle definitions > and descriptions wouldn't belong in the core uapi header. So I think that's > just confusing and I'd drop opaque from the description and just call it a > token. hmm, to me, 'opaque' just meant 'do not try to interpret the bits'.. but if that is confusing, I don't mind to just call it a token > (And another reason why I was suggesting to split the space for potential > common and vendor/driver specific tokens.) (which works well until some vendor introduces some format, and later another vendor adds support for it :-P) BR, -R > Regards, > > Tvrtko _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
