[RFC PATCH] drm: Add plane event
Jesse Barnes
jbarnes at virtuousgeek.org
Wed Apr 18 08:57:01 PDT 2012
On Wed, 18 Apr 2012 16:58:36 +0200
Marcus Lorentzon <marcus.xm.lorentzon at stericsson.com> wrote:
> On 04/18/2012 04:26 PM, Ville Syrjälä wrote:
> Yes, from previous emails I have seen that we are quite aligned on the
> single-atomic-modeset-with-properties version.
>
> Do you have any actual proposal for this? Like the API at least and some
> comments on "the other limitations" you fix with it?
> I only recall seeing Jesse's API proposal, but not yours, only some
> ideas about a generic list of properties/values for modeset when I
> proposed something similar.
I've been talking with Ville in private about this a little. Doing
things well means a few additional APIs and properties, but I don't
think he has anything concrete yet (I expect he's hacking on something
now and probably has it working, just not to his satisfaction :p).
> I'm about to implement atomic modeset now one way or the other, so the
> more proposals I have to choose from the better ;)
> I found that the per-crtc modeset above covers my requirements, so I
> might just take the easy route for now. But I welcome any work/proposal
> on generic support for atomic modeset.
I think Daniel summarized it well; it would be good to have an atomic
mode set to change the whole device configuration atomically (including
timings and other properties that involve global computation about
memory bandwidth etc), and a separate ioctl for flipping new buffers
onto one or more planes associated with a given pipe, along with
ancillary data that may be needed (sprite position, z order, gamma,
etc).
This could easily spiral out of control though, given how poorly the
existing KMS API expresses the variety of display controllers out
there; hopefully we can keep things incremental.
--
Jesse Barnes, Intel Open Source Technology Center
More information about the dri-devel
mailing list