This patch implements the notification of clients during mode_switch.
As discussed on IRC, clients are notified of mode_switch only when the
"native" mode is changed and activated. That means that if the native
mode is changed and the compositor had activated a temporary mode for
a fullscreen surface, the clients will be notified only when the native
mode is restored.
The scaling factor is treated the same way as modes.
This allows a surface to live on after its resource has been
destroyed. The ref-count can be increased in a resource destroy signal
listener, to keep the surface around for a destroy animation, for example.
Don't NULL the resource pointer before calling weston_surface_destroy().
We use to have more of a distinction between compositor created surfaces
and client surfaces, and weston_surface_destroy couldn't be used for
client surfaces. Now it all goes through weston_surface_destroy() and
we can remove the assert and the NULL-ing of resource, which caused the
marshalling warning.
The list of surfaces used by weston_compositor_pick_surface() is
maintained in list of surfaces stored on the compositor. This list is
generated from the surfaces across all the layers using
weston_compositor_build_surface_list.
When destroying a surface the surface is "unmapped" with
weston_surface_unmap which removes it from the layer list. However since
the compositor surface list was only being rebuilt when the output was
repainted a call to weston_compositor_pick_surface before the next
output repaint would use an outdated surface list containing surfaces
that have been partially destroyed.
https://bugs.freedesktop.org/show_bug.cgi?id=65986https://bugs.freedesktop.org/show_bug.cgi?id=66173https://bugs.freedesktop.org/show_bug.cgi?id=66198
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>
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>
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>
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.
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]
exit() calls atexit() handlers and C++ destructors (e.g. a C++
weston module) which could destroy state that the main process
depends on (e.g. ioctl's, tmpfiles, sockets, etc...). If an exec
fails, call _exit() instead of exit().
v2: prefer _exit over _Exit
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
It may happen that you e.g. fullscreen a 800x600 surface with
buffer_scale 1 (e.g. a 800x600 buffer) on an output that is
otherwise scale 2. In this case we want to temporarily set
the output scale to 1, as we're really scanning out of a
scale 1 buffer. This causes us to e.g. report the input
positions in the right place, etc.
When we restore the original mode we also restore the original
scale.
Note that the scale change is a purely compositor internal change,
to clients it still looks like the output is scale 2.
We changed the protocol to always list modes in physical pixel
units (not scaled). And we removed the scaled mode flag. This
just updates the DRM and X11 compositors and the gl and pixman renderers
to handle this.
The current config parser, parses the ini file and pulls out the values
specified by the struct config_section passed to parse_config_file() and
then throw the rest away. This means that every place we want to get
info out of the ini file, we have to parse the whole thing again. It's not
a big overhead, but it's also not a convenient API.
This patch adds a parser that parses the ini file to a data structure and
puts that in weston_compositor->config along with API to query comfig
keys from the data structure. The old parser is still available, but
we'll transition to the new approach over the next few commits.
Replace the GL renderer with the new rpi-renderer on the Raspberry Pi
backend. This makes Weston on rpi not use EGL or GL anymore, at all.
The weston_plane feature is disabled, since the rpi-renderer does the
same, but better.
Add a command line option to select the output transform. It is not a
weston.ini option for now, since the rpi backend does not read the
configuration file yet. Hopefully that will be done later with some
shared code.
Add the rpi options to 'weston --help' output.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Both GL and pixman renderer (pixman probably only because GL did?)
return the screen capture image as y-flipped, therefore Weston y-flips
it again. However, the future rpi-renderer can produce only right-way-up
(non-flipped) screen captures, and does not need an y-flip.
Add a capability flag for y-flip, which the rpi-renderer will not set,
to get screen captures the right way up.
The wcap recording code needs yet another temporary buffer for the
non-flipped case, since the WCAP format is flipped, and the code
normally overwrites the input image as it compresses it. This becomes
difficult, if the compressor is supposed to flip while processing.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The upcoming rpi-renderer cannot handle arbitrary rotations. Introduce
Weston capability bits, and add a bit for arbitrary rotation. GL and
Pixman renderers support it.
Shell or any other module must not produce surface transformations with
rotation, if the capability bit is not set. Do not register the surface
rotation binding in desktop shell, if arbitary rotation is not
supported.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If you specify e.g. scale=2 in weston.ini an output section for the
X11 backend we automatically upscale all normal surfaces by this
amount. Additionally we respect a buffer_scale set on the buffer to
mean that the buffer is already in a scaled form.
This works with both the gl and the pixman renderer. The non-X
backends compile and work, but don't support changing the output
scale (they do downscale as needed due to buffer_scale though).
This also sends the new "scale" and "done" events on wl_output,
making clients aware of the scale.
The only way to create a sub-surface loop by recursive nesting is to
make the main surface (which does not have a role) a sub-surface of any
of its sub-surfaces. All other cases should already be cought.
This change checks for that exact case, and sends a protocol error.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
wl_subsurface.set_desync should apply the cached wl_surface state.
Otherwise, the sub-surface may be stuck: a commit on the parent surface,
if desynchronized, will not commit the sub-surface because it is
desynchronized, too. A commit on the sub-surface may not happen, if it
is waiting for the frame callback from the previous commit.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This set of changes adds support for searching for a given config file
in the directories listed in $XDG_CONFIG_DIRS if it wasn't found in
$XDG_CONFIG_HOME or ~/.config. This allows packages to install custom
config files in /etc/xdg/weston, for example, thus allowing them to
avoid dealing with home directories.
To avoid a TOCTOU race the config file is actually open()ed during the
search. Its file descriptor is returned and stored in the compositor
for later use when performing subsequent config file parses.
Signed-off-by: Ossama Othman <ossama.othman@intel.com>
The subsurface-server-protocol.h header should not be included
by any headers that are part of the SDK since it is not exported.
Otherwise, SDK consumers will break during compilation.
Move this include from compositor.h to compositor.c.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=64537
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>