It seems good to use a dedicated type for keycodes, particularly given
there's two conventions for keycodes, offset by 8. So there's ambiguity
about what the numberic value of the keycode actually represents.
We might prefer to use the Wayland value rather than the X11 version
like `xkeysym::KeyCode` uses. But it would complicate things to have two
different keycode types, and the code that calls `kbd.key` already is
converting from `Keycode`.
some drivers might offer multiple cursor planes per CRTC.
in this case try to use the first unclaimed plane and try to
keep the same for as long as possible
some drivers might offer multiple candidates as the
primary plane for a CRTC. pick one and claim it so that
we do not accidentially select the same plane multiple times.
Surface position in global compositor space is not required to be
rounded to logical integers. The compositor is free to put surfaces
wherever. So, do not require an integer-logical position.
Not to be confused with:
* A subsurface can only be at an integer-logical offset from its parent
surface (for now, at least). However, this is unrelated to the
subsurface position in the global compositor space.
* A surface buffer is (generally expected to be) at an integer
*physical* pixel position. However, this is unrelated, and frequently
isn't, an integer *logical* pixel position.
Before this patch, `AnvilState<BackendData>`,
`AnvilState<Backend: crate::state::Backend>`, and `AnvilState<B>` are
mixed up. This patch uses `AnvilState<BackendData>` for consistency.
The event structs were already defined and used in `TouchTarget`, but
there was no way to actually send them.
I would also add backend support for getting these events from libinput,
but apparently that still doesn't exist:
https://gitlab.freedesktop.org/libinput/libinput/-/issues/746.
...and use it to associate wl_surfaces to X11 surfaces.
The xwayland shell protocol moves the responsibility of setting the
"xwayland_surface" role on the wl_surface from the x11 side of the connection to
the wayland side. Among other things, this avoids the xwm racing the lifecycle
of the surface.
Since we can check the serial with a commit hook, this also removes the need for
a ugly idle callback in the Xwm, and may allow for better separation of concerns in the
future, for example moving the association state tracking out of Xwm.
Even when handling request for a surface, `surface.client()` may return
`None`. This occurs, for example, if a protocol error is signaled; the surface
remains alive for some time, but `client()` returns `None` immediately after
`post_error` was called.
This method, while undocumented, is a lot more robust than an intermediate
shell. It works by passing a pipe to the Xwayland cmdline invocation. When
Xwayland is ready, it writes the display number and a newline to the pipe.
While we're at it, we can remove the hard dependency on Calloop, so that the
Xwayland instance can be used with other event loops.
Each call to `set_text_input_rectangle` changes the position of the
popup and also will result in popup repositioning, thus notify
users when such request occurs.
The location and text cursor area where separated, since one is used
for the rendering, and the other one is original location.
This fixes an issue I noticed where cancelled drag-and-drop in clients
like Firefox and Nautilus caused a window to ignore pointer events until
losing and regaining focus. It seems calling the `.ungrab` method at the
end of `with_grab` means calling it after pointer focus is restored, and
clients seem not to handle the `wl_pointer.enter` before the drag is
actually over.
Deferring the focus restoration as well is slightly complicated to
implement, and seems problematic when it involves a serial. Maybe there
shouldn't be any input events after the `*set_grab` call but before
returning, but this seems cleaner.
Taking a reference to the handler in `*InterHandle.*set_grab` is a bit
annoying, but easy enough to deal with, and allows this to work more
cleanly. This seems reasonable as long as we don't have a better
solution to the whole `GrabStatus::Borrowed` thing.
This was already supposed to happen, but I hadn't noticed that these
functions don't delegate to a method of the innter handle, like they do
with touch.
This is a breaking API change, since these functions then need to take
`&mut D`. But this seems reasonable since the equivalents for
pointer/touch already require that, and `&mut D` should be available to
call wherever these are used.
`unset` is called when a grab is removed with `unset_grab` or replaced
with `set_grab`.
This fixes https://github.com/pop-os/cosmic-comp/issues/403. There are a
couple other grabs in Smithay and cosmic-comp that they run before
unsetting the grab, that may cause issues if the grab is removed without
running it. So this seems useful in general.
The usual value for one wheel tick is 15, not 3. This can be verified
with Firefox by scrolling on a TTY backend vs. on the winit backend
(since this particular fallback is used on the winit backend).
