Destroying the whole output in reenable would cause list walk corruption: the loop over output_list in session_notify() is not using wl_list_for_each_safe so output removal would break it. Creating a new output is also problematic as it needs the compositor to configure it, but that probably saved us from another list walk failure: adding the new output to be list while walking the list, possibly causing it to be destroyed and re-created ad infinitum. Instead of a complete destroy/create cycle, just do our internal disable/enable cycle. That will re-open the fbdev, re-read the parameters, re-create hw_surface, and reinitialize the renderer output. A problem with this is if fbdev_set_screen_info() fails. We do read the new parameters, but we don't communicate them to libweston core or old clients. However, it is hard to care: to trigger this path, one needs to VT-switch to another fbdev app which changes the fbdev parameters. That is quite difficult as VT-switching has been broken for a good while for fbdev-backend, at least with logind. Also fbdev_set_screen_info() would have to fail before one should be able to tell something is wrong. The real reason behind this patch, though, is the migration to the head-based output API. Destroying and re-creating an output really does not fit that design. Destroying and re-creating a head would be better, but again not testable in the current state. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Ian Ray <ian.ray@ge.com> Acked-by: Daniel Stone <daniels@collabora.com> Acked-by: Derek Foreman <derekf@osg.samsung.com>dev
parent
388646506b
commit
55916d54ce
Loading…
Reference in new issue