On 22 September 2015 at 01:49, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Thu, Sep 17, 2015 at 05:51:28PM +0800, Xinliang Liu wrote: > > On 17 September 2015 at 04:16, Daniel Vetter <daniel at ffwll.ch> 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. > âOh, that's great!â This sounds a great way. That might solve my problem. I'll try. Thanks. âBest, -Xinliang â > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150924/ffb7c090/attachment.html>
