config.h includes were missing in a few files, including input.c, the
lack of which caused the X11 backend to segfault instantly due to not
having an xkbcommon context.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This removes the use of wl_client_get_display() where the client is
derived from the focussed resource. This starts the removal of the
assumption of a single resource on a client that would be notified about
events on the focussed surface.
This commit sets the version numbers for all added/created objects. The
wl_compositor.create_surface implementation was altered to create a surface
with the same version as the underlying wl_compositor. Since no other
"child interfaces" have version greater than 1, they were all hard-coded to
version 1.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
In embedded environments, devices that appear as evdev "keyboards" often
have no resemblence to PC-style keyboards. It is not uncommon for such
environments to have no concept of modifier keys and no need for XKB key
mapping; in these cases libxkbcommon initialization becomes unnecessary
startup overhead. On some SOC platforms, xkb keymap compilation can
account for as much as 1/3 - 1/2 of the total compositor startup time.
This patch introduces a 'use_xkbcommon' flag in the core compositor
structure that indicates whether the compositor is running in "raw
keyboard" mode. In raw keyboard mode, the compositor bypasses all
libxkbcommon initialization and processing. 'key' events containing the
integer keycode will continue to be delivered via the wl_keyboard
interface, but no 'keymap' event will be sent to clients. No modifier
handling or keysym mapping is performed in this mode.
Note that upstream sample apps (e.g., weston-terminal or the
desktop-shell client) will not recognize raw keycodes and will not react
to keypresses when the compositor is operating in raw keyboard mode.
This is expected behavior; key events are still being sent to the
client, the client (and/or its toolkit) just isn't written to handle
keypresses without doing xkb keysym mapping. Applications written
specifically for such embedded environments would be handling keypresses
via the raw keycode delivered as part of the 'key' event rather than
using xkb keysym mapping.
Whether to use xkbcommon is a global option that applies to all
compositor keyboard devices on the system; it is an all-or-nothing flag.
This patch simply adds conditional checks on whether xkbcommon is to be
used or not.
v3 don't send zero as the file descriptor - instead send the result of
opening /dev/null
v2 by Rob Bradford <rob@linux.intel.com>: the original version of the
patch used a "raw_keycodes" flag instead of the "use_xkbcommon" used in
this patch.
v1: Reviewed-by: Singh, Satyeshwar <satyeshwar.singh@intel.com>
v1: Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
This change tweaks weston_pointer_clamp to take into consideration if a
seat is constrained to a particular output by only considering the
pointer position valid if it is within the output we a constrained to.
This function is also used for the initial warping of the pointer when a
constraint is first established.
The other two changes are the application of the constraint when either
a new device added or a new output created and therefore outputs and
input devices can be brought up in either order.
v2: the code in create_output_for_connector has been spun off into a
new function setup_output_seat_constraint (Ander). The inappropriate
warping behaviour has been resolved by using weston_pointer_clamp
(Pekka).
This refactors the code out from clip_pointer_motion into a function of
its own which can then be used elsewhere to clamp the pointer
coordinates to the range of the outputs.
This change also makes the caller of clip_pointer_motion use this new
function.
With the change to move free()ing of the wl_resource into wayland-server, we now have
a few cases where we double free the resource in the destructor. This patch
removes those.
This is the first in what will be a series of weston patches to convert
instances of wl_resource to pointers so we can make wl_resource opaque.
This patch handles weston_surface and should be the most invasive of the
entire series. I am sending this one out ahead of the rest for review.
Specifically, my machine is not set up to build XWayland so I have no
ability to test it fully. Could someone please test with XWayland and let
me know if this causes problems?
Because a surface may be created from XWayland, the resource may not always
exist. Therefore, a destroy signal was added to weston_surface and
everything used to listen to surface->resource.destroy_signal now listens
to surface->destroy_signal.
It was erronously using output->current->height in one
place where it should use output->height. This may cause
it to create an invalid clipped coordinate in case of output
scaling or transform, because the next round "prev" would
end up NULL.
Currently the core input code does surface picking before calling into
the focus callback of the current grab. Not all grabs need to pick a
surface however, so we're doing work we don't have to in those cases.
For example, the shell move and resize grabs don't need to pick and the
default grab in implicit grab mode doesn't either.
With this change, the pointer grab mechanism is now very simple:
the focus callback is called whenever the pointer may have a new focus,
the motion callback is called whenever the pointer moves and
the button callback whenever a button is pressed or released.
This was another complication that we had to have to support the
split between libwayland-server and weston. Different grabs want to send
events relative to different surfaces at different times. The default
grab switches between sending coordinates relative to the 'current' surface,
that is the surface the pointer is currently above, or the 'clicked'
surface, in case of an implicit grab.
The grab focus was set by the grab implementation and the core input code
would transform the pointer position to surface relative coordinates for the
grab focus and store in grab->x/y.
Now we can just let the grab implementation transform the pointer
coordinates itself, leaving the implementation free to transform
according to whichever surface it wants. Or not transform at all if
it doesn't need surface relative coordinates (like the shell move and resize
grabs).
The current surface field was used to track the surface the pointer was
currently over along with pointer position relative to that surface,
regardless of implicit or explicit grabs. The main purpose was to restore
the default grab when another grab terminated. We can now just repick in
that case and avoid keeping that state around, with the destroy listener
overhead that involves.
There was one other use case - we used to optimize out calls to
weston_pointer_set_focus() if the focus didn't actually change. We can
still do that, but we have to do that in the default_grab_focus() handler
and compare against weston_pointer->focus instead.
struct weston_surface is now the only surface type we have (in core, shell.c
has shell_surface, of course). A lot of code gets simpler and we never
have to try to guess whether an API takes a wl_surface or a weston_surface.
We can now update the drag icon position directly from the configure
handler or the grab motion handler, and no longer need
weston_seat_update_drag_surface().
Daniel Stone
Rob Bradford
Rusty Lynch
Peter Hutterer
Kristian Høgsberg
Michael Fu
Giulio Camuffo
Jason Ekstrand
Matt Roper
Alexander Larsson