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

Greg Hackmann ghackmann at google.com
Wed Mar 26 14:21:41 PDT 2014


On Thu, Mar 20, 2014 at 5:28 PM, Rob Clark <robdclark at gmail.com> wrote:

> oh, that's right.. I'm glad you reminded me, I do remember now talk of
> a field which drivers could use to return some opaque (to drm core)
> handle/value/token/whatever..
>
> hmm, for the non-vsync'd multi-display case, does it matter much one
> ioctl per display vs one globally?
>
> If no, I'd vote for just one output field in the ioctl struct which
> can be whatever the driver wants it to.. that would be pretty simple.


If you're planning to support generic clients, you'd at least need some way
to indicate the output contains an fd that the client's responsible for
closing.  Otherwise it would leak a fence (or whatever fd-backed object
that's being returned) each time it updates the display.


> > 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.
>
> Well, I suspect that this is in the HWC HAL at all is a strong
> indication that we should think about including this somehow in the
> atomic ioctl.. considering that the trend for wayland compositors is a
> fairly generic userspace just using kms+gbm directly.  I suspect the
> alternative will only be an atomic2 ioctl at some point ;-)
>

These policies are complicated enough that I'm skeptical you could push
them into the kernel without making the drivers really large and
complicated.  A typical HWC HAL will have thousands of lines of code plus
pull in other helper libraries, and the bulk of that will be for planning
the composition in the prepare() op.  Maybe you could break some of that
out into common helper code, but IME and IMO the hardware constraints are
too different from SoC to SoC for that to scale.

That said, I'd be happy to be proven wrong -- if the hypothetical atomic2
ioctl has a kernel counterpart that I'm comfortable recommending to
vendors, being able to write a single generic HWC HAL would be good for
Android too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/156b99a2/attachment.html>


More information about the dri-devel mailing list