Not sure if there's a better way to organize this, but this makes sure
`visible_output_for_surface` can find an output and schedule a render,
on initial configure.
Fixes https://github.com/pop-os/cosmic-comp/issues/476.
This should fix https://github.com/pop-os/cosmic-comp/issues/494, and
make clipboard and primary focus consistently correct.
Changing the active element of a stack needs to change the clipboard
focus, but it wasn't being changed since the `KeyboardFocusTarget` was
unchanged. The `CosmicStack` methods that change the active stack
element also have no obvious way to change the keyboard focus. So we can
set this in `refresh_focus`, which should be correct.
If the new focus `WlSurface` is `None`, this clears the focus instead of
leaving it as the previous code did. I believe that is desirable.
Requires https://github.com/Smithay/smithay/pull/1442 to avoid repeated
`offer`s, instead of only when focus changed.
(Perhaps this could better be solved by having a `WlSurface` variant of
`KeyboardFocusTarget`, like pointer focus, or some mechanism for a stack
of focus, which could help other things. But it's also unclear exactly
how that would work with the code for setting the active stack element,
among other questions.)
Cosmic-workspaces was having an issue when the compositor sent `ready`,
`failed`, then `stopped`. This could be worked around client-side, but
presumably the compositor should never send more than one
`failed`/`ready` for a particular frame.
It seems cleaner to have `FrameInner::fail` as the only place that sends
`failed`. So any checks can be there. I believe the logic there should
be appropriate for every call.
Before this, `/proc/$(pidof cosmic-comp)/maps` quickly expands in length
when cosmic-workspaces is opened and closed a bunch of time, preventing
the GPU memory from being freed. Which on my Intel system can lead to
OOM eventually.
There may be other leaks to deal with, but `maps` no longer shows this
issue.
It doesn't seem there's currently a way to iterate over input devices,
so this adds a `Vec` of libinput keyboard devices. When run with the
kms backend.
Not the most elegant solution, but it doesn't seem practical to add a
type generic to `Devices` given how backends are handled, and `Device`
can't be made into a trait object. Another trait could be added, but
this is fine, and technically should perform better (but if it actually
had to iterate over many keyboards, something has gone very wrong).
