Consider a simple client that doesn't use set_window_geometry,
committing after attaching a buffer to a window surface.
Window::geometry falls back to Window::bbox, but when
Shell::map_window called Window::geometry, Window::bbox hadn't been
set yet, because that only happened later in
<State as CompositorHandler>::commit, so the window would be mapped
with a size of (0, 0).
This resulted in server-side decorations not being drawn for such
clients until they were re-focused or resized.
The fix is to add an extra call to Window::on_commit() before mapping
it, so that its bbox is set correctly when Shell::map_window asks for
its geometry.
I didn't see any issue with how mouse events were handled, but a bisect
showed b818a68a91 caused the issue.
Reverting the definition of `element_under` to the version before that
change fixed the behavior.
Comparing what both versions return, the right element is returned, but
the location returned is wrong. This makes the return value match the
position that was returned by the previous implementation. It seems to
be working correctly now.
Fixes https://github.com/pop-os/cosmic-comp/issues/161.
The protocol doesn't specify this, but XWayland does assume relative
pointer events are part of a frame.
This works for now, though a better solution will be needed in Smithay
to also handle pointer constraints where a relative motion may occur
alone, etc.
This seems to fix https://github.com/pop-os/cosmic-comp/issues/159.
This is not a setting handled by libinput; we have to scale the
scrolling ourselves.
This should match the behavior of the `scroll_factor` defined in
sway-input(5).
This adds a `input-default` setting, which is used for input settings if a
device isn't set in `input-devices`. More awkwardly, it also adds an
`input-touchpad` setting, which is used instead of `input-default` for
touchpad devices, so we can separate mouse and touchpad settings even
though they use the same capability and settings.
This no longer sets the input config, and only reads it. If we add a UI
for per-device config, we'll need some IPC mechanism to list connected
devices. (Assuming cosmic-settings can't use libinput directly for that.)
This moves `InputConfig` and `XkbConfig` to a new `cosmic-comp-config`
crate, so they can be used in `cosmic-settings`.
The Intel driver (at least) pads the stride to meet the requirements for
scanout on AMD or Nvidia cards, when this flag is set.
This works around the bug I've seen in the Nvidia driver with corruption
importing an unaligned dmabuf. This presumably is an issue in the Nvidia
driver, but presumably it the fix would be for the import to fail, so
using a stride that allows it to succeed is better anyway.
This was setting the wrong order, and thus also fighting with
`raise_window`, creating a flood of configure events. Which seemed to
break submenus in Gimp when multiple toplevels were open.
This appears to be correct.
`or.geometry()` was actually calling a different method in `filter` than
in `.flat_map`. Apparently since `or` in `filter` is an `&&X11Surface`
instead of `&X11Surface`, that invoked the trait method on `SpaceElement`...
Smithay should be changed in some way so that can't happen, but this
improves some of the behavior in cosmic-comp for now, at least. There
may be other issues related to this.
The `SpaceElement::geometry` was also returning a `loc` of `(0, 0)`,
which presumably isn't correct either.
