Smithay
`wl_output`: Allow deleting all modes
While it currently is possible to remove Modes from an smithay::wayland::output::Output again, this requires keeping track of all added modes to do so.
The more common use-case is to re-scan the backend for supported modes, if something changes. In that case I have an updated list of supported modes that I want to be reflected by the wl_output object, but I have no idea, what modes were previously added (except for the currently active maybe).
A quick and dirty solution is to delete the Output and create a new one, but I propose to add a function to remove all previously added modes instead.
What are your thoughts on this @vberger ?
I think we should be able to add a set_modes(&self, &[Mode]) method directly, replacing the previous contents list.
Though, what is a realistic explanation for an output changing its supported modes ?
We should take into account the fact that the wayland protocol does not support advertising that a mode is no longer supported, so a radical change of supported modes is probably better reflected a the suppression of the output and the creation of a new one...
There are two cases for this:
- Nested backends that may use almost every value as a
Mode. - Mirroring outputs, which should only expose modes supported by both monitors.
For case one this would mean re-creating wl_output for every change in size of the compositor window, no idea what is the best practice here.
For the second case it might be better to just re-create the output, but technically the output being rendered to is still the same just with some new constraints given by the added mirror. Although one could argue, that the combination of two outputs results in a new output. I really have no idea what the best practice is here and how weston or gnome for example do handle this.
Not sure what would be the best choice...
For context, Weston's drawing area is not resized when started as an X client and its window size changes. Causing black borders or part of the wayland screen being cut.
I will try to figure out what gnome does on multi-monitor setups. I find weston's "solution" to the problem rather ugly. I guess we will end up just recreating the output in either case.