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.