On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote: > > On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote: > > > On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote: > > >> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart wrote: > > > > [snip] > > > > >> Should we add that to crtc helpers, instead of the current "just try to > > >> smash the old config on top of the ill-defined hw state after a failed > > >> modeset"? > > > > > > It would probably make sense to add a rollback operation to undo the > > > prepare operation, or maybe just a rollback/commit flag to the commit > > > operation. We would still need to smash the old config back though, as > > > the rollback operation shouldn't be expected to handle encoders and > > > connectors. > > > > > > While we're at it, shouldn't we make drivers report supported formats for > > > the main frame buffer, like we do for planes ? That would allow catching > > > format errors before calling the prepare operation. > > > > Yeah, I've noticed that one, too. I guess we could tackle that as part > > of an eventual "make the implicit primary plane a bit more explict" > > project. For now I'm not too offended by the duplication of checks. > > It would be nice to treat the primary plane as all the other planes. Several > embedded display engines don't make the primary plane special and just paint > the background with a plain color when the enabled planes don't cover the > entire display.
Same deal for some intel hardware (at least partially). Anyways, my current plan is that we fix it for the atomic pageflip/modeset stuff. Ie. I don't even want expose the CRTC scanout stuff in the new atomic API. -- Ville Syrj?l? Intel OTC
