On Thu, Aug 29, 2013 at 3:01 AM, Daniel Vetter <daniel.vetter at ffwll.ch>
wrote:
> On Thu, Aug 29, 2013 at 5:51 AM, Rob Clark <robdclark at gmail.com> wrote:
>>> 1. The API is geared toward updating one object at a time. Android's
>>> graphics stack needs the entire screen updated atomically to avoid tearing,
>>> and on some SoCs to avoid wedging the display hardware. Rob Clark's atomic
>>> modeset patchset worked, but copy/update/commit design meant the driver had
>>> to keep a lot more internal state.
>>>
>>
>> I'm not entirely sure how to avoid that, because at least some hw we
>> need to have the entire new-state in order to validate if it is
>> possible. I'm open to suggestions, of course, but the approach I was
>> going for was to at least do most of the boring work for this in
>> drm/kms core (ie. w/ the drm_{plane,crtc,etc}_state stuff)
>
> Yeah, I think Rob's design that trickle-feeds the entire state to the
> driver is ok (preferrably using a driver-allocated state tracking
> object or so). And then we'll let some helper code make this sane for
> most drivers.
>
> I guess especially for pageflips a mode where we just pass in new
> buffers (and leave all the blending as-is) would be useful, maybe we
> could add a flag that says "keep all other properties as-is". A second
> flag for "reset properties to defaults" would also be good, where
> default = the primary plane can display unobstructed. So mostly just
> for boot splash screens, fbcon, ...
>
>>> 2. Some SoCs don't map well to KMS's CRTC + planes + encoders + connector
>>> model. At the time I was dealing with hardware where the blending engines
>>> didn't have their own framebuffer (they could only scan out constant colors
>>> or mix the output of other blocks), and you needed to gang several mixers
>>> together to drive high-res displays.
>>>
>>
>> currently you can connect a crtc to multiple encoders (at least for
>> some hw).. I suppose w/ the small addition of having a way to specify
>> an encoder's x/y offset, we could cover this sort of case?
>
> Hm, I've thought that if we convert the primary plane to a real plane
> we'd already have that. Then you can just place planes at x/y offset
> to construct the entire scanout area. Planes also have a crtc mask, as
> do connectors (through the encoders) so the n-to-m mapping is also
> possible on the output side afaics.
yeah, that is probably better
>>> 3. KMS doesn't support custom pixel formats, which a lot of newer SoCs use
>>> internally to cut down on bandwidth between hardware blocks.
>>
>> for custom formats, use a custom fourcc value, this should work.
>>
>> err, hmm, looks like some of the error checking that was added is a
>> bit too aggressive. What I'd propose is:
>>
>> #define DRM_FORMAT_CUSTOM 0x80000000
>>
>> and then 'if (format & DRM_FORMAT_CUSTOM) ... pass through to driver ..'
>
> Imo we should just convert primary planes to real planes so that we
> can do the same table-based checking for them as we do for secondary
> planes right now. And then we can just ditch format_check and allow
> drivers to use whatever pleases them. Of course reserving a driver
> specific range would be good, otoh we could just add more stuff to the
> drm_fourcc.h header.
agreed. But we also have to fix the format_check() when you try to
create an fb ;-)
BR,
-R
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
