On Thu, Jan 12, 2017 at 12:23:16PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 11, 2017 at 04:51:16PM -0800, Ben Widawsky wrote:
...
> > + memcpy(plane->modifiers, format_modifiers,
> > + format_modifier_count * sizeof(format_modifiers[0]));
>
> Looks all right since we do the same for
Hey,
On 13 January 2017 at 09:37, Ville Syrjälä
wrote:
> On Thu, Jan 12, 2017 at 07:27:03PM +, Daniel Stone wrote:
>> It would make sense, but then gbm_surface_create_with_modifiers takes
>> a fixed pixel format and a list of acceptable modifiers (which to me
>> seems like the right way aroun
On Thu, Jan 12, 2017 at 07:27:03PM +, Daniel Stone wrote:
> Hi,
>
> On 12 January 2017 at 18:11, Ville Syrjälä
> wrote:
> > On Thu, Jan 12, 2017 at 05:50:15PM +, Daniel Stone wrote:
> >> struct drm_plane {
> >> struct {
> >> uint32_t format;
> >> uint64_t modifiers[];
Hi,
On 12 January 2017 at 18:11, Ville Syrjälä
wrote:
> On Thu, Jan 12, 2017 at 05:50:15PM +, Daniel Stone wrote:
>> struct drm_plane {
>> struct {
>> uint32_t format;
>> uint64_t modifiers[];
>> } formats[];
>> }
>
> Flipping formats[] vs. modifiers[] here would seem
On Thu, Jan 12, 2017 at 05:50:15PM +, Daniel Stone wrote:
> Hi,
>
> On 12 January 2017 at 17:45, Ville Syrjälä
> wrote:
> > On Thu, Jan 12, 2017 at 05:04:46PM +, Daniel Stone wrote:
> >> Implicit is clever but horrible. AFAICT, the only way to do it
> >> properly would be to have a nested
Hi,
On 12 January 2017 at 17:45, Ville Syrjälä
wrote:
> On Thu, Jan 12, 2017 at 05:04:46PM +, Daniel Stone wrote:
>> Implicit is clever but horrible. AFAICT, the only way to do it
>> properly would be to have a nested forwards loop walk when you first
>> hit a modifier, searching for further
On Thu, Jan 12, 2017 at 05:04:46PM +, Daniel Stone wrote:
> Hi,
>
> On 12 January 2017 at 14:56, Rob Clark wrote:
> > On Thu, Jan 12, 2017 at 4:38 AM, Ville Syrjälä
> > wrote:
> >> Isn't an implicit offset enough? As in first mask for a specific
> >> modifier is for format indexes 0-63, seco
Hi,
On 12 January 2017 at 14:56, Rob Clark wrote:
> On Thu, Jan 12, 2017 at 4:38 AM, Ville Syrjälä
> wrote:
>> Isn't an implicit offset enough? As in first mask for a specific
>> modifier is for format indexes 0-63, second mask for the same modifier
>> is for 64-127, and so on.
>
> hmm, hadn't t
On Thu, Jan 12, 2017 at 4:38 AM, Ville Syrjälä
wrote:
> On Wed, Jan 11, 2017 at 08:43:16PM -0500, Rob Clark wrote:
>> On Wed, Jan 11, 2017 at 7:51 PM, Ben Widawsky wrote:
>> >
>> > +struct drm_format_modifier {
>> > + /* Bitmask of formats in get_plane format list this info
>> > +*
On Wed, Jan 11, 2017 at 04:51:16PM -0800, Ben Widawsky wrote:
> Originally based off of a patch by Kristian.
>
> This new ioctl extends DRM_IOCTL_MODE_GETPLANE, by returning information
> about the modifiers that will work with each format.
>
> It's modified from Kristian's patch in that the modi
On Wed, Jan 11, 2017 at 08:43:16PM -0500, Rob Clark wrote:
> On Wed, Jan 11, 2017 at 7:51 PM, Ben Widawsky wrote:
> >
> > +struct drm_format_modifier {
> > + /* Bitmask of formats in get_plane format list this info
> > +* applies to. */
> > + uint64_t formats;
>
> re: the uabi
On Wed, Jan 11, 2017 at 7:51 PM, Ben Widawsky wrote:
>
> +struct drm_format_modifier {
> + /* Bitmask of formats in get_plane format list this info
> +* applies to. */
> + uint64_t formats;
re: the uabi, I'd suggest to at least make this 'u32 offset; u32
formats'.. we can keep
12 matches
Mail list logo
