It seems this was needed for `renderer.bind_wl_display`. But only in the
X11 and winit backends. Unless there's some less obvious reason to use
the `use_system_lib` feature, it seems undesirable and avoidable.
This uses `WlDrmState` to provide `wl_drm` on those backends instead.
We need to call `add_tablet` for each tablet device, not just if the
capability is new. Also, the tool needs to be added with `add_tool`.
`xournalpp` seems to be working now.
I wasn't sure if, or how, scaling should apply to the `scroll_value120`
events. But it seems both sway and kwin just multiply by the scale
factor then round, so that seems reasonable.
This seems to fix https://github.com/pop-os/cosmic-settings/issues/270.
Manually starting `cosmic-panel` was not working properly in release
builds, because without `cfg!(debug_assertions)`, the `privileged` flag
wasn't sent on the panel, so it couldn't be propagated to the applets,
which also fail the `client_has_no_security_context()` check.
I don't see a way to have both the `cfg!(debug_assertions)` check and
`COSMIC_ENABLE_WAYLAND_SECURITY`. Now only the latter is used, and it
determines the value of `privileged` for clients started normally. In
the future, we could make the default value of
`COSMIC_ENABLE_WAYLAND_SECURITY` depend on `cfg!(debug_assertions)` if
desired.
This also corrects the inconsistency that the `cfg!(debug_assertions)`
check wasn't applied to the render-node-specific Wayland sockets.
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.
We already direct touch events to Iced, and the Cosmic `HeaderBar`
widget already recognizes drags from touch events. So it seems updating
`last_seat` is all that was needed for windows SSDs.
For stacks, the same works, plus moving using the same logic for
detecting drags that is used for mouse events.
The default implementation always returned `Kind::Unspecified`. Instead,
we should pass this method through to the wrapped element.
This fixes the use of cursor planes. Now trace logs show Smithay
assigning an element to the cursor plane, and tools like `drm_info` show
the cursor plane with an `FB_ID` attached.
