On Mon, Apr 25, 2011 at 8:33 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote:
> On Mon, 25 Apr 2011 20:28:20 -0400
> Alex Deucher <alexdeucher@xxxxxxxxx> wrote:
>
>> On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote:
>> > On Mon, 25 Apr 2011 16:16:18 -0700
>> > Keith Packard <keithp@xxxxxxxxxx> wrote:
>> >
>> >> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote:
>> >>
>> >> > Overlays are a bit like half-CRTCs. They have a location and fb, but
>> >> > don't drive outputs directly. Add support for handling them to the core
>> >> > KMS code.
>> >>
>> >> Are overlays/underlays not associated with a specific CRTC? To my mind,
>> >> overlays are another scanout buffer associated with a specific CRTC, so
>> >> you'd create a scanout buffer and attach that to a specific scanout slot
>> >> in a crtc, with the 'default' slot being the usual graphics plane.
>> >
>> > Yes, that matches my understanding as well. I've deliberately made the
>> > implementation flexible there though, under the assumption that some
>> > hardware allows a plane to be directed at more than one CRTC (though
>> > probably not simultaneously).
>>
>> A lot of older hardware had one overlay that could be sourced to any
>> crtc, just not simultaneously. The tricky part is the formats and
>> capabilities: alpha blending, color/chromakey, gamma correction, etc.
>> Even the current crtc gamma stuff is somewhat lacking in in terms of
>> what hardware is capable of (PWL vs. LUT, user defined conversion
>> matrices, gamut remapping, etc.).
>
> Right, this implementation allows an overlay to be tied to any crtc
> listed in the possible_crtcs mask (matching the other possible_*
> fields), but only one at a time. I think that's fairly common.
>
> Agree about formats and capabilities. I think enumerating available
> formats is best, perhaps making that a driver specific array if we
> can't agree on a common set.
I would rather have format be common to all hardware, rather than
having a list per hardware. uint32_t would give enough room to add all
formats even if one format is only supported by one hardware only (at
one point in time). Also this would allow to have second dumb way to
allocate scanout buffer in non driver specific way. Maybe we need
another ioctl to query support format somethings like :
struct drm_format_supported {
uint32_t nformats;
uint32_t __user *formats;
};
Userspace supply an array of format and driver overwritte entry that
are not supported with 0, 0 would be a special INVALID format.
> Dealing with color correction could also be driver specific; once
> the client has an overlay id it can use driver specific ioctls to
> get/set specifics.
>
> --
> Jesse Barnes, Intel Open Source Technology Center
Is there that many different way to do color corrections ?
Cheers,
Jerome
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
