[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKMK7uHYgZQsWg6GQ9nwknNfAc0PV+WPgP9VBoiVhT+Eij0Seg@mail.gmail.com>
Date: Fri, 14 Oct 2016 16:56:25 +0200
From: Daniel Vetter <daniel@...ll.ch>
To: Brian Starkey <brian.starkey@....com>
Cc: Archit Taneja <architt@...eaurora.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
Liviu Dudau <liviu.dudau@....com>,
"Clark, Rob" <robdclark@...il.com>,
Hans Verkuil <hverkuil@...all.nl>,
Eric Anholt <eric@...olt.net>,
"Syrjala, Ville" <ville.syrjala@...ux.intel.com>
Subject: Re: [RFC PATCH 00/11] Introduce writeback connectors
On Fri, Oct 14, 2016 at 2:39 PM, Brian Starkey <brian.starkey@....com> wrote:
>> - Besides the above property, writeback hardware can have provisions
>> for scaling, color space conversion and rotation. This would mean that
>> we'd eventually add more writeback specific props/params in
>> drm_connector/drm_connector_state. Would we be okay adding more such
>> props for connectors?
>
>
> I've wondered the same thing about bloating non-writeback connectors
> with writeback-specific stuff. If it does become significant, maybe
> we should subclass drm_connector and add a drm_writeback_state pointer
> to drm_connector_state.
No pionters needed, just embedded drm_connector_state into
drm_writeback_connector_state as the "base" member. Then we can
provide ready-made atomic_set/get_property functions for the aditional
writeback functionality.
But tbh I'd only start doing that once we have a few more. It's purely
an implementation change, with no effect on userspace. And if you go
with my drm_writeback_connector_init idea, it won't even be an issue
for drivers.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Powered by blists - more mailing lists