| romangg |
| KWin |
XdgOutput no-ops if one calls setLogicalSize(someSize) and someSize matches the last sent size
However, as we have an explicit done signal, we currently end up sending this regardless.
This patches tracks if we've made any changes to commit in the done event.
CCBUG: 400987
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
I just tested it and it works. As you said in D19253 has same caveat as I pointed out not being in sync with wl_output::done event in case resolution and scale factor change at the same time such that logical size stays the same.
But let's merge this patch, which is nicer than my solution in D19253, as a quick fix for every other case.
Maybe add a TODO comment on merge to the setLogicalSize (that it does not handle the size plus scale change correctly in every case).
Maybe add a TODO comment on merge to the setLogicalSize (that it does not handle the size plus scale change correctly in every case).
Can you expand on what you mean?
I thought we discussed this problem already in the other diff. Example:
Single 4K Monitor is used in 1080p with 1 times scaling: logical size is 1080p
Now an atomic change comes of: Resolution set to 4K, scaling factor to 2. This triggers a wl_output::done event, but the logical size stays the same, i.e. not necessary set the dirty bit.
I just realize with our current KWin/KWayland code, which has to set the logical size on every pixelSize and scale change we do not have this problem at the moment, but later if we want to send only one done event per atomic configuration change a single wl_output::done event might be generated but not the respective xdg_output::done event.
I wouldn't say it's handling it incorrectly. In the scenario you've give the logical size hasn't changed.
a single wl_output::done event might be generated but not the respective xdg_output::done event.
I was under the impression that xwayland expects an xdg_output::done to have a corresponding wl_output::done, but not necessarily the other way round?
If we do need them to always be paired we'll have the same issue if you change refresh rate without changing the resolution.
The only long term option I can think of that would fix that is exposing the dirty bit publicly and having kwin do:
if (output->isDirty() || xdgOutput->isDirty()) {
output->done();
xdgOutput->done();
}(after porting Output to this same pattern)