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:
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.
Thanks,
-Xinliang
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
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
