[PATCH 00/16] Atomic/nuclear modeset/pageflip

[Greg Hackmann]

On Wed, Mar 19, 2014 at 5:23 AM, Rob Clark <robdclark at gmail.com> wrote:

> > Hm, do you have some pointers to read up on this? I still think a more
> > elaborate fail scheme is overkill, but maybe reading a bit of android
> code
> > convinces me differently ;-)
>
> sadly no pointers to anything to read (but ofc would be interested if
> anyone else does)..
>

The hardware composer HAL is probably the best reference for what Android
needs from display.  It's defined and documented here (see struct
hwc_composer_device_1):

*https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/hwcomposer.h
<https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/hwcomposer.h>*

(You can disregard any HWC 1.0 specific behavior in that documentation,
that's only around for legacy reasons and we strongly encourage vendors not
to implement HWC 1.0 anymore.)

Vendors need to ship a compliant HWC HAL implementation on their devices.
 We don't mandate anything about their userspace/kernel interface beyond
that.


>  * I kinda would still like to add to the atomic ioctl some way to indicate
>    ok/error on a bit finer granularity than per-ioctl.  Ie. perhaps an
>    array where userspace can ask for results per KMS object (crtc/plane)?
>    Something along these lines would give the kernel a bit more flexibility
>    to deal with some of the edge cases which come up when you gang crtcs
>    for ultra high resolution displays.  In short, it would let the driver
>    "steal" some of the planes if needed from userspace.
>
>    This would also, conveniently, be pretty similar to how (AFAIU) hw
>    compositor and ADF work on android.  Which seems like it would be useful
>    to eventually enable android devices to use an upstream display driver.
>
>    For this we could pretty easily just throw in a placeholder that we
>    could replace later with an optional ptr to __user array.  I think
>    that would be fine for an initial version, but I just wanted to throw
>    this idea out there, because I think it will become important.
>

SurfaceFlinger needs the HWC HAL to return a retire fence fd on each flip,
for each display.  Per-interface return data would be a good fit for this,
but per-CRTC or per-plane would work too (userspace could assemble a
per-interface fence by merging finer-grained fences).

It's up to the vendor whether their HWC HAL does fine-grained error
handling and renegotiation like you're describing.  Typically they don't,
they just push that complexity into userspace instead.  e.g. if the display
controller needs to gang together two planes for a given configuration, the
HWC HAL's prepare() op will already know to set aside that extra plane and
plan accordingly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/43734f08/attachment.html>