[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