On Thu, Mar 20, 2014 at 5:28 PM, Rob Clark <robdclark@xxxxxxxxx> wrote:
oh, that's right.. I'm glad you reminded me, I do remember now talk ofa 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 handlingWell, I suspect that this is in the HWC HAL at all is a strong
> 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.
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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
