<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 19, 2014 at 5:23 AM, Rob Clark <span dir="ltr"><<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>> Hm, do you have some pointers to read up on this? I still think a more<br>
> elaborate fail scheme is overkill, but maybe reading a bit of android code<br>
> convinces me differently ;-)<br>
<br>
</div></div>sadly no pointers to anything to read (but ofc would be interested if<br>
anyone else does)..<br></blockquote><div><br></div><div><div>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):</div>
<div><br></div><div><font color="#1155cc"><u><a href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/hwcomposer.h">https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/hwcomposer.h</a></u></font><br>
</div><div><font color="#1155cc"><u><br></u></font></div><div>(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.)</div>
<div>
<br></div><div>Vendors need to ship a compliant HWC HAL implementation on their devices. We don't mandate anything about their userspace/kernel interface beyond that.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style="font-family:arial,sans-serif;font-size:13px"> * I kinda would still like to add to the atomic ioctl some way to indicate</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> ok/error on a bit finer granularity than per-ioctl. Ie. perhaps an</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> array where userspace can ask for results per KMS object (crtc/plane)?</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> Something along these lines would give the kernel a bit more flexibility</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> to deal with some of the edge cases which come up when you gang crtcs</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> for ultra high resolution displays. In short, it would let the driver</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> "steal" some of the planes if needed from userspace.</span><br style="font-family:arial,sans-serif;font-size:13px"><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> This would also, conveniently, be pretty similar to how (AFAIU) hw</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> compositor and ADF work on android. Which seems like it would be useful</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> to eventually enable android devices to use an upstream display driver.</span><br style="font-family:arial,sans-serif;font-size:13px"><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> For this we could pretty easily just throw in a placeholder that we</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> could replace later with an optional ptr to __user array. I think</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> that would be fine for an initial version, but I just wanted to throw</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> this idea out there, because I think it will become important.</span><br>
</blockquote><div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div>
</div></div></div>