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.
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.
This commit converts shell_surface.resource to a pointers and updates
shell.c to use wl_resource_get accessors for shell_surface, desktop_shell,
screensaver, and workspace_manager related resources.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
xeyes works as expected now. subwindows are popped also as expected. This
patch should fix the following:
https://bugs.freedesktop.org/show_bug.cgi?id=59983
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
When printing debug information about atoms, the XWM would crash if the X
server failed to respond to a request about atom names. In practice this
occurred when the server itself crashed, e.g. when starting mplayer with the
"xv" vo.
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.
v4:
Incorporated krh and anderco's comments. Now adding newly allocated
buffer's dimensions to texture_damage
v3:
* Removed unnecessary parentheses
* Added check for switching from EGL image to SHM buffer
* Moved shader assignment out of IF condition
v2:
Fixed the wrong comparison
v1:
Depending on specific DRI driver implementation, glTexImage2D() with data
set to NULL may or may not re-allocate the texture buffer each time it is
called. Unintended consequences happen if later glTexSubImage2D() is called
to only update a sub-region of the texture buffer.
I've explored moving glTexImage2D() from gl_renderer_attach() and simply
mark the texture dirty, but the current implemention seems cleaner because
I won't have to worry about calling ensure_textures() and re-assigning
gs->shader unnecessarily.
AC_USE_SYSTEM_EXTENSIONS enables _XOPEN_SOURCE, _GNU_SOURCE and similar
macros to expose the largest extent of functionality supported by the
underlying system. This is required since these macros are often
limiting rather than merely additive, e.g. _XOPEN_SOURCE will actually
on some systems hide declarations which are not part of the X/Open spec.
Since this goes into config.h rather than the command line, ensure all
source is consistently including config.h before anything else,
including system libraries. This doesn't need to be guarded by a
HAVE_CONFIG_H ifdef, which was only ever a hangover from the X.Org
modular transition.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
[pq: rebased and converted more files]
Matt Roper
Rob Bradford
Alex Wu
Ander Conselvan de Oliveira
Kristian Høgsberg
Nathan Reboud
Jason Ekstrand
Giulio Camuffo
Quentin Glidic
Samuel Iglesias Gonsalvez
Tiago Vignatti
MoD
Eduardo Lima (Etrunko)
Sinclair Yeh
Daniel Stone