output: wlr_backend_commit and wlr_swapchain_helper #8068
Conversation
kennylevinsen
force-pushed
the
backendwide
branch
2 times, most recently
from
6a73030
to
0a481f5
Compare
kennylevinsen
force-pushed
the
backendwide
branch
from
0a481f5
to
ed4adc8
Compare
kennylevinsen
force-pushed
the
backendwide
branch
2 times, most recently
from
4e2585c
to
3aeb4dd
Compare
|
Had entirely forgotten to use the new swapchain in the |
kennylevinsen
force-pushed
the
backendwide
branch
from
3aeb4dd
to
c25564f
Compare
kennylevinsen
force-pushed
the
backendwide
branch
from
c25564f
to
0b450ca
Compare
|
I took the liberty of shortening some lines in the new apply_output_configs while I was addressing the comments - they had gotten a bit out of hand. |
| struct output_config *oc = find_output_config(output); | ||
| apply_output_config(oc, output); | ||
| free_output_config(oc); | ||
| apply_all_output_configs(); |
There was a problem hiding this comment.
Idea for future work: we could schedule a apply_all_output_configs() call with an idle event source (or a timer with a short duration), so that changes for multiple outputs are batched together (e.g. on startup, or when plugging a dock).
This would require a slightly better fallback logic though: if we can't enable all outputs we need to retry after lowering the modes and/or disabling outputs.
There was a problem hiding this comment.
In clay I run off an idle handler for new and destroyed outputs, and for wlr_output_power_management as those do not need any feedback. I also experimented with a timer, but it didn't seem to make much of a difference other than delaying bringup. Might be worth more experimentation.
It's a bit trickier when the trigger want feedback on success, e.g. dynamic configuration with swaymsg or wlr_output_management.
There was a problem hiding this comment.
Ref #8091 :)
It's a bit trickier when the trigger want feedback on success, e.g. dynamic configuration with swaymsg or wlr_output_management.
I don't think debouncing is particularly desirable in these cases.
|
By the way, we have some |
|
I've looked through all of the commits and they all LGTM! |
Agree. In clay I retry with a new set of output states that progressively get less demanding until something sticks. While that approach isn't per-output like the old logic, I think we could have some fairly simple "graceful degradation" logic here too.
Thanks for the review! |
Applying an output config has two stages: Atomic application of wlr_output_state, and applicaiton of non-atomic state like output layout. Split the latter out into finalize_output_config for use in a later commit.
Introduce apply_output_configs, which applies the specified matched output configs as a single backend commit. Reimplement apply_output_config_to_outputs using apply_output_configs.
Apply all output configs as they are. This differs from apply_output_config_to_outputs, which tries to apply a specific output config.
This allows us to test and if necessary degrade the entire backend configuration to light everything up.
apply_output_config_to_outputs uses the specified output config to check which outputs to apply to, and to use as backup when no config is found. If any config matches the output, the specified config will be disregarded. The only remaining user of apply_output_config_to_outputs is reset_outputs, which called apply_output_config_to_outputs with either the first stored wildcard config, or a new empty wildcard config. Providing a stored or empty wildcard config is practically the same as calling `apply_all_output_configs`. Replace uses of `reset_outputs` with `apply_all_output_configs` and remove the now unused functions.
kennylevinsen
force-pushed
the
backendwide
branch
from
0b450ca
to
2ba1f1e
Compare
|
re: our discussion about graceful fallback, I threw together something here: 18a1c26 It is untested, but the idea is to first degrade render formats to 8 bit, then degrade automatically selected modes, starting with the most bandwidth-intensive one. Problems:
|
Use the new
wlr_backend_commitandwlr_swapchain_helperto light up outputs and apply configuration changes.Works in local testing, but as sway's output configuration system is a bit complicated it wouldn't hurt with more testing.