Re: Design review request: DRM color manager

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for your time and the comments David.
please find mine inline.

Regards
Shashank
On 5/12/2014 5:20 PM, David Herrmann wrote:
Hi

On Mon, May 12, 2014 at 12:26 PM, Sharma, Shashank
<shashank.sharma@xxxxxxxxx> wrote:
Benefits of using color manager:
================================
1. Unique framework for all the color correction properties, across all
    DRM drivers, across various platforms.
2. Only one set/get call for all kind of properties using the common
protocol. One get call can tell what are the color correction capabilities
of the SOC, registered by driver.

What's the advantage of that? We should add a
DRM_MODE_OBJ_SET_PROPERTIES call if we want to accelerate things,
instead of adding huge payloads.

The problem here is a DRM_OBJECT_MODE_SET_PROPERTIES call can pass limited value. But there are few properties like gamma correction which need a full LUT(256 vals) to be passed according to the correction values. The plan here is pretty much aligned to your suggestion, ie to use DRM_OBJECT_MODE_SET_BLOB kind of property, and extract the data from the blob based on a protocol.
Why do you think its a huge payload ?
I really think we should define one property for each color-correction
interface. I cannot see any downside of that except that we should add
DRM_MODE_OBJ_SET_PROPERTIES.

As I was discussing, if there are 10 color correction properties a SOC supports, we have to create 10 properties which doesn't look good, when all the properties will do the same (set/reset few registers as correction). We already have a case where we expose 6 different type of corrections.

One more benefit is, this part is centrally controlled, so you can always know what's the state of color correction in single shot at any time. This will also provide us to do a lot of common things to do at the same place, like floating point arithmetic to register value conversion in a supporting userspace library, which might be required for many cases.

INHO, its always good to have a controlled interface/ framework to have similar things aligned to.

But afaik that's already the plan for
atomic-modesetting, right?

Thanks
David

AFAIK color management is not a part of atomic modeset, but once we create such an interface, it would be really easy to club that in the atomic modeset.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux