It seems that, on some systems (such as on mine), 1s is not long enough
for a spurious disconnect and reconnect to happen. 2s seems enough,
however, while still likely not being long enough to cause user
confusion.
BUG: 480026
Process the geometry update as usual but just avoid confuguring the x
windows. It simplifies the implementation of the move resize function
and makes it more refactorable.
GeometryUpdatesBlocker is unnecessary. One could just compute the
final geometry on a side and then issue one moveResize() rather than
call move(); resize(); moveResize() and so on in a sequence. The
advantage of the former approach over the latter is that the code
can be a bit more straightforward.
When a window is closed, its geometry should not change, so the geometry
updates blockers are not needed. There's also no code that could potentially
change the geometry in destroyWindow() or releaseWindow().
Drm planes aren't specialized enough to need completely separate code paths to
handle them, and having one class for all layers makes it easier to add support
for overlay planes
We have a bunch of logic in there that is effectively no-op if the
values don't change. We might as well skip it altogether and save some
code from being run to do nothing.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
While these geometry updates blockers are used in functions that can
call moveResize() several times in a row, it's not critical.
On the other hand, by removing these blockers, no other core code is
going to rely on GeometryUpdatesBlocker, which opens us the future
opportunitinies to drop it and make geometry manipulation code simpler.
Instead of the active screen being purely defined by the mouse position,
or purely defined by the active window and keyboard shortcuts, this changes
it to make the active screen all about the last user interaction. This should
work for most workflows without needing a setting to choose between two flawed
approaches.
BUG: 482865
BUG: 484902
BUG: 484902
There's a bunch of differences between them, like direct scanout, adaptive sync, content type
and the actually painted output in the Wayland session but not on Xorg, so keeping them in one
method doesn't really make sense
This simplifies how the stream resolution is updated and removes a couple
more of failure points. This also appears to fix window screencasts freezing
in obs when those windows are resized.
The existing check incorrectly compares the directory path only. This
allows unintended GPUs to be added when events occur for them, such
as with "udevadm trigger".
Update the check to use the full path.
This moves some of the responsbilities up in the stack, which simplifies
the backends and opens up some future possibilities like making direct scanout
work for non-surface items
ScreenCastStream::onStreamAddBuffer() can be called before the stream
params are updated. This is problematic because that function expects a
valid m_dmabufParams.
The reason why m_dmabufParams is reset is to force the onStreamParamChanged()
function to check whether dmabufs can be still allocated with the new size.
Also pull "Rows" out of the SpinBox into a dedicated label.
Both to address concerns "Add" about being misinterpreted as
"Add Row", given that the button to add a new virtual desktop
now sits right next to the row count spinner.
The steady clock is more preferred for generating timestamps because it
ensures that timestamps increase monotonically.
This fixes screencasts freezing in obs after changing the system time.
If the max framerate is 60Hz, currently, the frameInterval is going to
be 16.6ms. On the other hand, lastSentAgo is likely to be just 16ms. So
the frame throttling timer will be started just to wait less than a
millisecond.
Hidden moveResize() calls stand in the way of making geometry code
reusable or more refactorable. They also usually require one using
geometry update blockers, which are just a horrible concept because
they make geometry code unnecessarily more complex and add more failure
points.
The existing code overwrites all per-output data with the config from KScreen
every time an output config is found that isn't in the KWin data base yet.
That causes problems like the scale being reset to 1.0 if the user logged
into Xorg before, or resetting it to whatever scale KScreen had saved on
Wayland, which isn't much better.
Instead of doing that, use the KScreen config as inspiration for some specific
output settings, instead of copying it outright. It's not ideal, but it's
better than overwriting settings the user has explicitly set up
BUG: 485353
