Originally window.c was requesting version 1 but several clients were
calling version 2 and 3 events including the desktop shell itself.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Window contents cannot be assumed to be fully opaque for windows drawn with
a RGBA visual. The optimization of setting a full opaque region is limited to
windows with a color depth != 32.
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>
In preparation for upcoming changes, we want to make sure that apps
written with the toy toolkit continue to operate properly if no XKB
keymap is received. If there's no XKB keymap, then we shouldn't
try to figure out keyboard modifier states (since we probably don't
even have equivalents of PC-style modifiers).
Reviewed-by: Singh, Satyeshwar <satyeshwar.singh@intel.com>
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.
This change spills the code for looking up a seat by name and then
potentially creating it if it doesn't exist into a new function called
udev_seat_get_named.
This change allows us to reuse this code when looking up the seat
when parsing seat constraints per output.
The fix to not call glTexImage2D() on every attach does not properly
set the texture damage region appropriately when the surface has a
buffer transform with 90 or 270 degrees rotation, since it would simply
multiply the buffer dimensions by the buffer scale, but in this case
width and height are inverted.
A possible fix for this would be to add the properly transformed region
to the texture damage region. However, there is a conversion back to
buffer coordinates when doing the actual upload and the entire buffer
needs to be uploaded anyway. So we just set a flag signalling that and
handle that special case in gl_renderer_flush_damage().
Checking for gs->num_images for determining the previous buffer type
when attaching is not reliable. The number of images is never cleared
in the SHM path, so after a switch from an EGL buffer to SHM, every
following attach of an SHM buffer will happen with gs->num_images > 0,
and the code will assume the previous buffer was an EGL one.
Fix this by adding a buffer_type field to gl_surface_state.
We were assigning drag from the resource user data, which was wrong
(resource data is the weston_seat) and confusing since drag is later
assigned newly malloc()ed memory.
We used to refcount the data source, but switched to using a destroy signal
instead. When we switched we forgot to free the source insted of
unreffing it.
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 commit adds a weston_buffer structure to replace wl_buffer. This way
we can hold onto buffers by just their resource. In order to do this, the
every renderer.attach function has to fill in the weston_buffer.width and
weston_buffer.height fields.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Because of its links to selection.c and xwayland, a destroy_signal field
was also added to wl_data_source. Before selection.c and xwayland were
manually initializing the resource.destroy_signal field so that it could be
used without a valid resource.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Instead, forward signal to weston and wait for weston to clean up nicely.
Weston relies on weston-launch being around to shut down correctly,
so don't exit until we get the SIGCHLD from weston. This make
killall weston-launch work properly.
https://bugs.freedesktop.org/show_bug.cgi?id=62910
When the spring goes outside the envelope, we have a few options for
bringing it back: either just let it overshoot, bounce off the limit or
just clamp it. Instead of controlling that with #ifdef, let's make it
a part of the spring state.
The weston_spring is a very flexible and powerful mecanhism for driving
animations. However, it can be a little difficult to tame, but this
little helper can plot the response of the spring to a set of initial
parameters and makes it easy to tune and tweak the spring behavior.
Jason Ekstrand
MoD
David Richards
Daiki Ueno
Kristian Høgsberg
Rob Bradford
Matt Roper
Alex Wu
Ander Conselvan de Oliveira
Nathan Reboud
Giulio Camuffo
Quentin Glidic