On Thu, Sep 17, 2015 at 05:51:28PM +0800, Xinliang Liu wrote: > On 17 September 2015 at 04:16, Daniel Vetter <daniel@xxxxxxxx> wrote: > > > On Wed, Sep 16, 2015 at 04:23:35PM +0100, Daniel Stone wrote: > > > The biggest issue though, is that this driver should become an atomic > > > modesetting driver. Atomic modesetting, rather than sending small > > > individual commands (enable CRTC, change plane position, etc) is based > > > on validating and passing around complete sets of hardware state. > > > Daniel Vetter's blog has an article on how to convert your driver: > > > http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html > > > > Yeah, any new driver should really be built on top of atomic - it's a lot > > more flexible than the old thing and it's also what you want long-term. > > > > I've also just done a presenation about atomic for drivers: > > > > http://people.freedesktop.org/~danvet/presentations/xdc-2015.pdf > > > Hi Daniel, > This is a good presentation. It gives us very detail and good suggection on > implementation. > Thank you for sharing this. > > We have a open source KMS hwc: > wiki: > https://wiki.linaro.org/BenjaminGaignard/HWComposer_DRM?highlight=%28hwcomposer%2 > source code: git://git.linaro.org/people/benjamin.gaignard/hwcomposer.git > Now only STI and Hikey boards are tested on it. And atomic mode setting is > not support now. > I think we should add support for atomic mode setting next. > > One difficulty I am facing is that one setting should be made sure is ok in > the prepare function of hwc. > If not, the set function of hwc may be fail and display will not properly. > I don't know atomic mode setting how to handle this situation. And it seems > that in the prepare function, > it should check the hardware's capabilities, such as clip, scale, rotation, > blending and so on. Specifically to support things like hwc's ->prepare callback atomic supports a TEST_ONLY mode. Hence in your the prepare code build up the atomic state, but set the TEST_ONLY flag when calling the ioctl. When the kernel is happy you can store it somewhere and tell surface flinger the configuration so it can render the remaining buffers with GL. The idea is that generic userspace does use TEST_ONLY mode iterative to build up the maximal configuration of hw planes that a given kms driver supports, leaving no hw-specific code in userspace. For optimized hwc drivers running on atomic you then just need to tune the selection, but detailed constraint checking would still be done by the kernel. The weston patches from Daniel Stone have a similar design, would be worth checking those out. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
