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.
>> 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.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
