On Wed, 18 Apr 2012 16:58:36 +0200 Marcus Lorentzon <marcus.xm.lorentzon@xxxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
