On Thu, Mar 20, 2014 at 6:34 PM, Greg Hackmann <ghackmann at google.com> wrote: > 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 >
cool, thx for the link > (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). 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. > 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 ;-) A crazy idea.. if atomic ioctl could atomically both write and then read some properties. Maybe kill two birds with one stone by letting userspace both specify a set of properties it wants to write, and also a set to read. BR, -R >
