On Mon, Jul 13, 2015 at 11:32:09AM +0200, Maarten Lankhorst wrote: > Op 07-07-15 om 12:28 schreef Daniel Vetter: > > On Tue, Jul 07, 2015 at 09:08:20AM +0200, Maarten Lankhorst wrote: > >> Perform a full readout of the state by making sure the mode is set > >> up correctly atomically. > >> > >> Also there was a small memory leak by doing the memset, fix this > >> by calling __drm_atomic_helper_crtc_destroy_state first. > >> > >> Changes since v1: > >> - Moved after reworking primary plane and updating mode members. > >> - Force a modeset calculation by changing mode->type from what the > >> final mode will be. > >> > >> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> > > tbh I don't really like mode_from_pipe_config since it goes in reverse. > > With the adjust mode of config_compare we can compare different final hw > > states and make a call whether they match enough for modeset avoidance or > > not. mode_from_pipe_config otoh is a lie on panels where we can do > > upscaling, hence I'd like to remove it to avoid confusion. > What do you want the initial mode to be then? > > You need to fill in some mode to satisfy drm_atomic_crtc_check. All zeros? That would make it clear that we have a mode, and that we also have no idea really what it is ... Otoh I think you've convinced me now that we indeed do need a real mode object here to avoid other troubles (i.e. the entire discussion around initial fbcon modesets). Given that I'd guess even the slightly wrong fill_in_modes here with the change to set DRIVER_MODE would be ok. As long as we can guarantee that we'll get a full modeset eventually we should be fine I hope. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
