From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Vetter, Daniel" <daniel.vetter@intel.com>
Subject: Re: [PATCH 0/4] Color manager framework
Date: Thu, 11 Sep 2014 12:23:27 +0300 [thread overview]
Message-ID: <20140911092327.GH4193@intel.com> (raw)
In-Reply-To: <CAKMK7uFbAcoo4KDuO4xP5vdor9mL5SaC+3=m3V0DFM1tDU3kEg@mail.gmail.com>
On Thu, Sep 11, 2014 at 10:49:01AM +0200, Daniel Vetter wrote:
> On Thu, Sep 11, 2014 at 10:18 AM, Sharma, Shashank
> <shashank.sharma@intel.com> wrote:
> > Thanks Bob, Matt, Daniel for the review.
> > I will create a new patch set, complying all (almost :)) review comments from you all, and will float for review.
> >
> > Points I noted down overall:
> > 1. No need for separate arrays for names, sizes etc (:( )
> > 2. Create a _set_blob for blob_properties, and take that route for setting values of blob property in blob.
>
> Please coordinate with Rob Clark/Ville on this, since the atomic ioctl
> also needs a set_blob. I'm not sure whether they have this already
> even. Adding them.
I'm pretty sure I had the blob thing in my atomic code. Hmm, yeah I used
it to shovel the mode into the kernel.
>
> Also there's no need to block brightness/hue/... and such simpler
> properties on this, so best to submit patches in parallel and
> prioritize some of the simpler ones to get those in first.
Yes, please pick one hardware knob at a time and come up with a sane way
to represent that as a property. Let's not make things more complicated
by trying to refactor the code too much or come up with fancy new
frameworks. Just one property at a time please.
As for designing the properties I'd like them to have these properties:
- hardware agnostic if possible, ie. multiple drivers should be able to
expose the same property and the compositor should not have to know
which driver it's talking to.
- precisely describe what transformation is done to the data so that
the compositor could have a fair chance of doing the same
transformation via GL when not using hardware planes
Obviously those may not always be possible, but we should at least try
to come up with something like that before giving up and just shoveling
some hardware specific magic number across.
--
Ville Syrjälä
Intel OTC
prev parent reply other threads:[~2014-09-11 9:23 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-23 18:04 [PATCH 00/11]: Color manager framework for I915 driver shashank.sharma
2014-07-23 18:04 ` [PATCH 01/11] drm/i915: Color manager framework for valleyview shashank.sharma
2014-07-23 18:04 ` [PATCH 02/11] drm/i915: Register pipe level color properties shashank.sharma
2014-07-25 0:02 ` Matt Roper
2014-07-23 18:04 ` [PATCH 03/11] drm/i915: Register plane " shashank.sharma
2014-07-23 18:04 ` [PATCH 04/11] drm/i915: Add color manager CSC correction shashank.sharma
2014-07-23 18:04 ` [PATCH 05/11] drm/i915: Add color manager gamma correction shashank.sharma
2014-07-23 18:05 ` [PATCH 06/11] drm/i915: Add contrast and brightness correction shashank.sharma
2014-07-23 18:05 ` [PATCH 07/11] drm/i915: Add hue and saturation correction shashank.sharma
2014-07-23 18:05 ` [PATCH 08/11] drm/i915: Add CRTC set property functions shashank.sharma
2014-07-23 18:05 ` [PATCH 09/11] drm/i915: Add set plane " shashank.sharma
2014-07-23 18:05 ` [PATCH 10/11] drm/i915: Plug-in color manager init shashank.sharma
2014-07-23 18:05 ` [PATCH 11/11] drm/i915: Plug-in color manager exit shashank.sharma
2014-07-23 18:34 ` [PATCH 00/11]: Color manager framework for I915 driver Daniel Vetter
2014-07-24 4:08 ` Sharma, Shashank
2014-07-25 0:43 ` Matt Roper
2014-07-25 4:36 ` Sharma, Shashank
2014-07-26 1:58 ` Matt Roper
2014-07-28 4:57 ` Sharma, Shashank
2014-09-09 6:23 ` [PATCH 0/4] Color manager framework shashank.sharma
2014-09-09 6:23 ` [PATCH 1/4] drm/i915: Color manager framework for valleyview shashank.sharma
2014-09-09 22:51 ` Bob Paauwe
2014-09-10 8:40 ` Sharma, Shashank
2014-09-10 16:25 ` Bob Paauwe
2014-09-10 1:29 ` Matt Roper
2014-09-10 11:20 ` Sharma, Shashank
2014-09-10 21:17 ` Matt Roper
2014-09-11 7:52 ` Daniel Vetter
2014-09-09 6:23 ` [PATCH 2/4] drm/i915: Plug-in color manager attach shashank.sharma
2014-09-10 1:29 ` Matt Roper
2014-09-10 11:52 ` Sharma, Shashank
2014-09-09 6:23 ` [PATCH 3/4] drm/i915: CSC color correction shashank.sharma
2014-09-09 22:51 ` Bob Paauwe
2014-09-10 8:55 ` Sharma, Shashank
2014-09-10 16:03 ` Bob Paauwe
2014-09-10 1:30 ` Matt Roper
2014-09-10 6:40 ` Daniel Vetter
2014-09-10 12:05 ` Sharma, Shashank
2014-09-10 12:13 ` Daniel Vetter
2014-09-10 22:17 ` Matt Roper
2014-09-11 7:53 ` Daniel Vetter
2014-09-09 6:23 ` [PATCH 4/4] drm/i915: Add set_protpery function shashank.sharma
2014-09-10 1:28 ` [PATCH 0/4] Color manager framework Matt Roper
2014-09-10 11:08 ` Sharma, Shashank
2014-09-10 18:15 ` Matt Roper
2014-09-11 7:56 ` Daniel Vetter
2014-09-11 8:18 ` Sharma, Shashank
2014-09-11 8:49 ` Daniel Vetter
2014-09-11 9:23 ` Ville Syrjälä [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140911092327.GH4193@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox