On Wed, Mar 19, 2014 at 5:23 AM, Rob Clark robdclark@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/incl... 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.