Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
/*
|
|
|
|
* Copyright © 2008-2011 Kristian Høgsberg
|
|
|
|
* Copyright © 2012, 2017, 2018, 2021 Collabora, Ltd.
|
|
|
|
* Copyright © 2017, 2018 General Electric Company
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining
|
|
|
|
* a copy of this software and associated documentation files (the
|
|
|
|
* "Software"), to deal in the Software without restriction, including
|
|
|
|
* without limitation the rights to use, copy, modify, merge, publish,
|
|
|
|
* distribute, sublicense, and/or sell copies of the Software, and to
|
|
|
|
* permit persons to whom the Software is furnished to do so, subject to
|
|
|
|
* the following conditions:
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the
|
|
|
|
* next paragraph) shall be included in all copies or substantial
|
|
|
|
* portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
|
|
|
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
|
|
|
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
|
|
|
|
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
|
|
|
|
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
|
|
|
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
|
|
* SOFTWARE.
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _WAYLAND_SYSTEM_COMPOSITOR_H_
|
|
|
|
#define _WAYLAND_SYSTEM_COMPOSITOR_H_
|
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#include <stdbool.h>
|
|
|
|
#include <stdint.h>
|
|
|
|
#include <time.h>
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
#include <pixman.h>
|
|
|
|
#include <xkbcommon/xkbcommon.h>
|
|
|
|
|
|
|
|
#define WL_HIDE_DEPRECATED
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
#include <wayland-server.h>
|
|
|
|
|
|
|
|
#include <libweston/matrix.h>
|
|
|
|
#include <libweston/zalloc.h>
|
|
|
|
|
|
|
|
struct weston_geometry {
|
|
|
|
int32_t x, y;
|
|
|
|
int32_t width, height;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_position {
|
|
|
|
int32_t x, y;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_size {
|
|
|
|
int32_t width, height;
|
|
|
|
};
|
|
|
|
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
struct weston_transform {
|
|
|
|
struct weston_matrix matrix;
|
|
|
|
struct wl_list link;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
};
|
|
|
|
|
|
|
|
/** 2D device coordinates normalized to [0, 1] range */
|
|
|
|
struct weston_point2d_device_normalized {
|
|
|
|
double x;
|
|
|
|
double y;
|
|
|
|
};
|
|
|
|
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
struct weston_surface;
|
|
|
|
struct weston_buffer;
|
|
|
|
struct shell_surface;
|
|
|
|
struct weston_seat;
|
|
|
|
struct weston_output;
|
|
|
|
struct input_method;
|
|
|
|
struct weston_pointer;
|
|
|
|
struct linux_dmabuf_buffer;
|
|
|
|
struct weston_recorder;
|
|
|
|
struct weston_pointer_constraint;
|
|
|
|
struct ro_anonymous_file;
|
color: introduce weston_color_profile
Roughly speaking, a color profile describes the color space of content
or an output. Under the hood, the description includes one or more ways
to map colors between the profile space and some standard profile
connecting space (PCS).
This object is not called a color space. A color space has a unique
definition, while a color profile may contain multiple different
mappings depending on render intent. Some of these mappings may be
subjective, with an artistic touch.
When a source color profile and a destination color profile are combined
under a specific render intent, they produce a color transformation.
Color transformations are already preresented by weston_color_transform.
This patch adds the basic API for color profile objects. Everything
worthwhile of these objects is implemented in the color managers:
color-noop never creates these, and in color-lcms they are basically a
container for cmsHPROFILE, the Little CMS object for color profiles.
Color profile objects will not be interpreted outside of the color
managers, unlike color transformations.
For a start, the color manager API has one function to create color
profiles: from ICC profile data. More creation functions for other
sources will be added later.
The API has errmsg return parameter for error messages. These are not
simply weston_log()'d, because CM&HDR protocol will allow clients to
trigger errors and the protocol handles that gracefully. Therefore
instead of flooding the compositor logs, the error messages will
probably need to be relayed back to clients.
Color-lcms is expected to create a cmsHPROFILE for all kinds of color
profiles, not just for those created from ICC profile data. Hence,
color-lcms will fingerprint color profiles by the MD5 hash which Little
CMS computes for us. The fingerprint is used for de-duplication: instead
of creating copies, reference existing color profiles.
This code is very much based on Sebastian Wick's earlier work on Weston
color management, but structured and named differently.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
4 years ago
|
|
|
struct weston_color_profile;
|
|
|
|
struct weston_color_transform;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
|
|
|
enum weston_keyboard_modifier {
|
|
|
|
MODIFIER_CTRL = (1 << 0),
|
|
|
|
MODIFIER_ALT = (1 << 1),
|
|
|
|
MODIFIER_SUPER = (1 << 2),
|
|
|
|
MODIFIER_SHIFT = (1 << 3),
|
|
|
|
};
|
|
|
|
|
|
|
|
enum weston_keyboard_locks {
|
|
|
|
WESTON_NUM_LOCK = (1 << 0),
|
|
|
|
WESTON_CAPS_LOCK = (1 << 1),
|
|
|
|
};
|
|
|
|
|
|
|
|
enum weston_led {
|
|
|
|
LED_NUM_LOCK = (1 << 0),
|
|
|
|
LED_CAPS_LOCK = (1 << 1),
|
|
|
|
LED_SCROLL_LOCK = (1 << 2),
|
|
|
|
};
|
|
|
|
|
compositor-drm: Add aspect-ratio parsing support
The flag bits 19-22 of the connector modes, provide the aspect-ratio
information. This information can be stored in flags bits of the
weston mode structure, so that it can used for setting a mode with a
particular aspect-ratio.
Currently, DRM layer supports aspect-ratio with atomic-modesetting by
default. For legacy modeset path, the user-space needs to set the
drm client cap for aspect-ratio, if it wants aspect-ratio information
in modes.
This patch:
- preserves aspect-ratio flags from kernel video modes and
accommodates it in wayland mode.
- uses aspect-ratio to pick the appropriate mode during modeset.
- changes the mode format in configuration file weston.ini to
accommodate aspect-ratio information as:
WIDTHxHEIGHT@REFRESH-RATE ASPECT-RATIO
The aspect-ratio can take the following values :
4:3, 16:9, 64:27, 256:135.
v2: As per recommendation from Pekka Paalanen, Quentin Glidic,
Daniel Stone, dropped the aspect-ratio info from wayland protocol,
thereby avoiding exposure of aspect-ratio to the client.
v3: As suggested by Pekka Paalanen, added aspect_ratio field to store
aspect-ratio information from the drm. Also added drm client
capability for aspect-ratio, as recommended by Daniel Vetter.
v4: Minor modifications and fixes as suggested by Pekka Paalanen.
v5: Rebased, fixed some styling issues, and added aspect-ratio
information while printing weston_modes.
v6: Moved the man pages changes to a different patch. Minor
reorganization of code as suggested by Pekka Paalanen.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
[Pekka: replace ARRAY_SIZE with ARRAY_LENGTH]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
73 years from now
|
|
|
enum weston_mode_aspect_ratio {
|
|
|
|
/** The picture aspect ratio values, for the aspect_ratio field of
|
|
|
|
* weston_mode. The values here, are taken from
|
|
|
|
* DRM_MODE_PICTURE_ASPECT_* from drm_mode.h.
|
|
|
|
*/
|
|
|
|
WESTON_MODE_PIC_AR_NONE = 0, /* DRM_MODE_PICTURE_ASPECT_NONE */
|
|
|
|
WESTON_MODE_PIC_AR_4_3 = 1, /* DRM_MODE_PICTURE_ASPECT_4_3 */
|
|
|
|
WESTON_MODE_PIC_AR_16_9 = 2, /* DRM_MODE_PICTURE_ASPECT_16_9 */
|
|
|
|
WESTON_MODE_PIC_AR_64_27 = 3, /* DRM_MODE_PICTURE_ASPECT_64_27 */
|
|
|
|
WESTON_MODE_PIC_AR_256_135 = 4, /* DRM_MODE_PICTURE_ASPECT_256_135*/
|
|
|
|
};
|
|
|
|
|
|
|
|
enum weston_surface_protection_mode {
|
|
|
|
WESTON_SURFACE_PROTECTION_MODE_RELAXED,
|
|
|
|
WESTON_SURFACE_PROTECTION_MODE_ENFORCED
|
|
|
|
};
|
compositor-drm: Add aspect-ratio parsing support
The flag bits 19-22 of the connector modes, provide the aspect-ratio
information. This information can be stored in flags bits of the
weston mode structure, so that it can used for setting a mode with a
particular aspect-ratio.
Currently, DRM layer supports aspect-ratio with atomic-modesetting by
default. For legacy modeset path, the user-space needs to set the
drm client cap for aspect-ratio, if it wants aspect-ratio information
in modes.
This patch:
- preserves aspect-ratio flags from kernel video modes and
accommodates it in wayland mode.
- uses aspect-ratio to pick the appropriate mode during modeset.
- changes the mode format in configuration file weston.ini to
accommodate aspect-ratio information as:
WIDTHxHEIGHT@REFRESH-RATE ASPECT-RATIO
The aspect-ratio can take the following values :
4:3, 16:9, 64:27, 256:135.
v2: As per recommendation from Pekka Paalanen, Quentin Glidic,
Daniel Stone, dropped the aspect-ratio info from wayland protocol,
thereby avoiding exposure of aspect-ratio to the client.
v3: As suggested by Pekka Paalanen, added aspect_ratio field to store
aspect-ratio information from the drm. Also added drm client
capability for aspect-ratio, as recommended by Daniel Vetter.
v4: Minor modifications and fixes as suggested by Pekka Paalanen.
v5: Rebased, fixed some styling issues, and added aspect-ratio
information while printing weston_modes.
v6: Moved the man pages changes to a different patch. Minor
reorganization of code as suggested by Pekka Paalanen.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
[Pekka: replace ARRAY_SIZE with ARRAY_LENGTH]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
73 years from now
|
|
|
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
struct weston_mode {
|
|
|
|
uint32_t flags;
|
compositor-drm: Add aspect-ratio parsing support
The flag bits 19-22 of the connector modes, provide the aspect-ratio
information. This information can be stored in flags bits of the
weston mode structure, so that it can used for setting a mode with a
particular aspect-ratio.
Currently, DRM layer supports aspect-ratio with atomic-modesetting by
default. For legacy modeset path, the user-space needs to set the
drm client cap for aspect-ratio, if it wants aspect-ratio information
in modes.
This patch:
- preserves aspect-ratio flags from kernel video modes and
accommodates it in wayland mode.
- uses aspect-ratio to pick the appropriate mode during modeset.
- changes the mode format in configuration file weston.ini to
accommodate aspect-ratio information as:
WIDTHxHEIGHT@REFRESH-RATE ASPECT-RATIO
The aspect-ratio can take the following values :
4:3, 16:9, 64:27, 256:135.
v2: As per recommendation from Pekka Paalanen, Quentin Glidic,
Daniel Stone, dropped the aspect-ratio info from wayland protocol,
thereby avoiding exposure of aspect-ratio to the client.
v3: As suggested by Pekka Paalanen, added aspect_ratio field to store
aspect-ratio information from the drm. Also added drm client
capability for aspect-ratio, as recommended by Daniel Vetter.
v4: Minor modifications and fixes as suggested by Pekka Paalanen.
v5: Rebased, fixed some styling issues, and added aspect-ratio
information while printing weston_modes.
v6: Moved the man pages changes to a different patch. Minor
reorganization of code as suggested by Pekka Paalanen.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
[Pekka: replace ARRAY_SIZE with ARRAY_LENGTH]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
73 years from now
|
|
|
enum weston_mode_aspect_ratio aspect_ratio;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
int32_t width, height;
|
|
|
|
uint32_t refresh;
|
|
|
|
struct wl_list link;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_animation {
|
|
|
|
void (*frame)(struct weston_animation *animation,
|
|
|
|
struct weston_output *output,
|
|
|
|
const struct timespec *time);
|
|
|
|
int frame_counter;
|
|
|
|
struct wl_list link;
|
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
WESTON_SPRING_OVERSHOOT,
|
|
|
|
WESTON_SPRING_CLAMP,
|
|
|
|
WESTON_SPRING_BOUNCE
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_spring {
|
|
|
|
double k;
|
|
|
|
double friction;
|
|
|
|
double current;
|
|
|
|
double target;
|
|
|
|
double previous;
|
|
|
|
double min, max;
|
|
|
|
struct timespec timestamp;
|
|
|
|
uint32_t clip;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* bit compatible with drm definitions. */
|
|
|
|
enum dpms_enum {
|
|
|
|
WESTON_DPMS_ON,
|
|
|
|
WESTON_DPMS_STANDBY,
|
|
|
|
WESTON_DPMS_SUSPEND,
|
|
|
|
WESTON_DPMS_OFF
|
|
|
|
};
|
|
|
|
|
|
|
|
/* enum for content protection requests/status
|
|
|
|
*
|
|
|
|
* This enum represents the content protection requests and statuses in
|
|
|
|
* libweston and its enum values correspond to those of 'type' enum defined in
|
|
|
|
* weston-content-protection protocol. The values should exactly match to the
|
|
|
|
* values of the 'type' enum of the protocol.
|
|
|
|
*/
|
|
|
|
|
|
|
|
enum weston_hdcp_protection {
|
|
|
|
WESTON_HDCP_DISABLE = 0,
|
|
|
|
WESTON_HDCP_ENABLE_TYPE_0,
|
|
|
|
WESTON_HDCP_ENABLE_TYPE_1
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Weston test suite quirks
|
|
|
|
*
|
|
|
|
* There are some things that need a specific behavior when we run Weston in the
|
|
|
|
* test suite. Tests can use this struct to select for certain behaviors.
|
|
|
|
*
|
|
|
|
* \sa compositor_setup
|
|
|
|
* \ingroup testharness
|
|
|
|
*/
|
|
|
|
struct weston_testsuite_quirks {
|
|
|
|
/** Force GL-renderer to do a full upload of wl_shm buffers. */
|
|
|
|
bool gl_force_full_upload;
|
|
|
|
/** Ensure GL shadow fb is used, and always repaint it fully. */
|
|
|
|
bool gl_force_full_redraw_of_shadow_fb;
|
|
|
|
/** Required enum weston_capability bit mask, otherwise skip run. */
|
|
|
|
uint32_t required_capabilities;
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Weston test suite data that is given to compositor
|
|
|
|
*
|
|
|
|
* It contains two members:
|
|
|
|
*
|
|
|
|
* 1. The struct weston_testsuite_quirks, which can be used by the tests to
|
|
|
|
* change certain behavior of Weston when running these tests.
|
|
|
|
* 2. The void *test_private_data member which can be used by the testsuite of
|
|
|
|
* projects that uses libweston in order to give arbitrary test data to the
|
|
|
|
* compositor. Its type should be defined by the testsuite of the project.
|
|
|
|
*
|
|
|
|
* \sa compositor_setup
|
|
|
|
* \ingroup testharness
|
|
|
|
*/
|
|
|
|
struct weston_testsuite_data {
|
|
|
|
struct weston_testsuite_quirks test_quirks;
|
|
|
|
void *test_private_data;
|
|
|
|
};
|
|
|
|
|
|
|
|
/** EOTF mode for outputs and heads
|
|
|
|
*
|
|
|
|
* A list of EOTF modes for driving displays, defined by CTA-861-G for
|
|
|
|
* Dynamic Range and Mastering InfoFrame.
|
|
|
|
*
|
|
|
|
* On heads, a bitmask of one or more entries shows which modes are claimed
|
|
|
|
* supported.
|
|
|
|
*
|
|
|
|
* On outputs, the mode to be used for driving the video sink.
|
|
|
|
*
|
|
|
|
* For traditional non-HDR sRGB, use WESTON_EOTF_MODE_SDR.
|
|
|
|
*/
|
|
|
|
enum weston_eotf_mode {
|
|
|
|
/** Invalid EOTF mode, or none supported. */
|
|
|
|
WESTON_EOTF_MODE_NONE = 0,
|
|
|
|
|
|
|
|
/** Traditional gamma, SDR luminance range */
|
|
|
|
WESTON_EOTF_MODE_SDR = 0x01,
|
|
|
|
|
|
|
|
/** Traditional gamma, HDR luminance range */
|
|
|
|
WESTON_EOTF_MODE_TRADITIONAL_HDR = 0x02,
|
|
|
|
|
|
|
|
/** Preceptual quantizer, SMPTE ST 2084 */
|
|
|
|
WESTON_EOTF_MODE_ST2084 = 0x04,
|
|
|
|
|
|
|
|
/** Hybrid log-gamma, ITU-R BT.2100 */
|
|
|
|
WESTON_EOTF_MODE_HLG = 0x08,
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Bitmask of all defined EOTF modes */
|
|
|
|
#define WESTON_EOTF_MODE_ALL_MASK \
|
|
|
|
((uint32_t)(WESTON_EOTF_MODE_SDR | WESTON_EOTF_MODE_TRADITIONAL_HDR | \
|
|
|
|
WESTON_EOTF_MODE_ST2084 | WESTON_EOTF_MODE_HLG))
|
|
|
|
|
|
|
|
/** CIE 1931 xy chromaticity coordinates */
|
|
|
|
struct weston_CIExy {
|
|
|
|
float x;
|
|
|
|
float y;
|
|
|
|
};
|
|
|
|
|
|
|
|
enum weston_hdr_metadata_type1_groups {
|
|
|
|
/** weston_hdr_metadata_type1::primary is set */
|
|
|
|
WESTON_HDR_METADATA_TYPE1_GROUP_PRIMARIES = 0x01,
|
|
|
|
|
|
|
|
/** weston_hdr_metadata_type1::white is set */
|
|
|
|
WESTON_HDR_METADATA_TYPE1_GROUP_WHITE = 0x02,
|
|
|
|
|
|
|
|
/** weston_hdr_metadata_type1::maxDML is set */
|
|
|
|
WESTON_HDR_METADATA_TYPE1_GROUP_MAXDML = 0x04,
|
|
|
|
|
|
|
|
/** weston_hdr_metadata_type1::minDML is set */
|
|
|
|
WESTON_HDR_METADATA_TYPE1_GROUP_MINDML = 0x08,
|
|
|
|
|
|
|
|
/** weston_hdr_metadata_type1::maxCLL is set */
|
|
|
|
WESTON_HDR_METADATA_TYPE1_GROUP_MAXCLL = 0x10,
|
|
|
|
|
|
|
|
/** weston_hdr_metadata_type1::maxFALL is set */
|
|
|
|
WESTON_HDR_METADATA_TYPE1_GROUP_MAXFALL = 0x20,
|
|
|
|
|
|
|
|
/** all valid bits */
|
|
|
|
WESTON_HDR_METADATA_TYPE1_GROUP_ALL_MASK = 0x3f
|
|
|
|
};
|
|
|
|
|
|
|
|
/** HDR static metadata type 1
|
|
|
|
*
|
|
|
|
* The fields are defined by CTA-861-G except here they use float encoding.
|
|
|
|
*
|
|
|
|
* In Weston used only with HDR display modes.
|
|
|
|
*/
|
|
|
|
struct weston_hdr_metadata_type1 {
|
|
|
|
/** Which fields are valid
|
|
|
|
*
|
|
|
|
* A bitmask of values from enum weston_hdr_metadata_type1_groups.
|
|
|
|
*/
|
|
|
|
uint32_t group_mask;
|
|
|
|
|
|
|
|
/* EOTF is tracked externally with enum weston_eotf_mode */
|
|
|
|
|
|
|
|
/** Chromaticities of the primaries, in any order */
|
|
|
|
struct weston_CIExy primary[3];
|
|
|
|
|
|
|
|
/** White point chromaticity */
|
|
|
|
struct weston_CIExy white;
|
|
|
|
|
|
|
|
/** Maximum display mastering luminance, 1 - 65535 cd/m² */
|
|
|
|
float maxDML;
|
|
|
|
|
|
|
|
/** Minimum display mastering luminance, 0.0001 - 6.5535 cd/m² */
|
|
|
|
float minDML;
|
|
|
|
|
|
|
|
/** Maximum content light level, 1 - 65535 cd/m² */
|
|
|
|
float maxCLL;
|
|
|
|
|
|
|
|
/** Maximum frame-average light level, 1 - 65535 cd/m² */
|
|
|
|
float maxFALL;
|
|
|
|
};
|
|
|
|
|
|
|
|
enum weston_color_characteristics_groups {
|
|
|
|
/** weston_color_characteristics::primary is set */
|
|
|
|
WESTON_COLOR_CHARACTERISTICS_GROUP_PRIMARIES = 0x01,
|
|
|
|
|
|
|
|
/** weston_color_characteristics::white is set */
|
|
|
|
WESTON_COLOR_CHARACTERISTICS_GROUP_WHITE = 0x02,
|
|
|
|
|
|
|
|
/** weston_color_characteristics::max_luminance is set */
|
|
|
|
WESTON_COLOR_CHARACTERISTICS_GROUP_MAXL = 0x04,
|
|
|
|
|
|
|
|
/** weston_color_characteristics::min_luminance is set */
|
|
|
|
WESTON_COLOR_CHARACTERISTICS_GROUP_MINL = 0x08,
|
|
|
|
|
|
|
|
/** weston_color_characteristics::maxFALL is set */
|
|
|
|
WESTON_COLOR_CHARACTERISTICS_GROUP_MAXFALL = 0x10,
|
|
|
|
|
|
|
|
/** all valid bits */
|
|
|
|
WESTON_COLOR_CHARACTERISTICS_GROUP_ALL_MASK = 0x1f
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Basic display color characteristics
|
|
|
|
*
|
|
|
|
* This is a simple description of a display or output (monitor) color
|
|
|
|
* characteristics. The parameters can be found in EDID, with caveats. They
|
|
|
|
* are particularly useful with HDR monitors.
|
|
|
|
*/
|
|
|
|
struct weston_color_characteristics {
|
|
|
|
/** Which fields are valid
|
|
|
|
*
|
|
|
|
* A bitmask of values from enum weston_color_characteristics_groups.
|
|
|
|
*/
|
|
|
|
uint32_t group_mask;
|
|
|
|
|
|
|
|
/* EOTF is tracked externally with enum weston_eotf_mode */
|
|
|
|
|
|
|
|
/** Chromaticities of the primaries */
|
|
|
|
struct weston_CIExy primary[3];
|
|
|
|
|
|
|
|
/** White point chromaticity */
|
|
|
|
struct weston_CIExy white;
|
|
|
|
|
|
|
|
/** Display's desired maximum content peak luminance, cd/m² */
|
|
|
|
float max_luminance;
|
|
|
|
|
|
|
|
/** Display's desired minimum content luminance, cd/m² */
|
|
|
|
float min_luminance;
|
|
|
|
|
|
|
|
/** Display's desired maximum frame-average light level, cd/m² */
|
|
|
|
float maxFALL;
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Represents a head, usually a display connector
|
|
|
|
*
|
|
|
|
* \rst
|
|
|
|
See :ref:`libweston-head`. \endrst
|
|
|
|
*
|
|
|
|
* \ingroup head
|
|
|
|
*/
|
|
|
|
struct weston_head {
|
|
|
|
struct weston_compositor *compositor; /**< owning compositor */
|
|
|
|
struct wl_list compositor_link; /**< in weston_compositor::head_list */
|
|
|
|
struct wl_signal destroy_signal; /**< destroy callbacks */
|
|
|
|
|
|
|
|
struct weston_output *output; /**< the output driving this head */
|
|
|
|
struct wl_list output_link; /**< in weston_output::head_list */
|
|
|
|
|
|
|
|
struct wl_list resource_list; /**< wl_output protocol objects */
|
|
|
|
struct wl_global *global; /**< wl_output global */
|
|
|
|
|
|
|
|
struct wl_list xdg_output_resource_list; /**< xdg_output protocol objects */
|
|
|
|
|
|
|
|
int32_t mm_width; /**< physical image width in mm */
|
|
|
|
int32_t mm_height; /**< physical image height in mm */
|
|
|
|
|
|
|
|
/** WL_OUTPUT_TRANSFORM enum to apply to match native orientation */
|
|
|
|
uint32_t transform;
|
|
|
|
|
|
|
|
char *make; /**< monitor manufacturer (PNP ID) */
|
|
|
|
char *model; /**< monitor model */
|
|
|
|
char *serial_number; /**< monitor serial */
|
|
|
|
uint32_t subpixel; /**< enum wl_output_subpixel */
|
|
|
|
bool connection_internal; /**< embedded monitor (e.g. laptop) */
|
|
|
|
bool device_changed; /**< monitor information has changed */
|
|
|
|
|
|
|
|
char *name; /**< head name, e.g. connector name */
|
|
|
|
bool connected; /**< is physically connected */
|
|
|
|
bool non_desktop; /**< non-desktop display, e.g. HMD */
|
|
|
|
uint32_t supported_eotf_mask; /**< supported weston_eotf_mode bits */
|
|
|
|
|
|
|
|
/** Current content protection status */
|
|
|
|
enum weston_hdcp_protection current_protection;
|
|
|
|
|
|
|
|
/** Opaque pointer used by backends to identify heads as theirs */
|
|
|
|
const void *backend_id;
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Output properties derived from its color characteristics and profile
|
|
|
|
*
|
|
|
|
* These are constructed by a color manager.
|
|
|
|
*
|
|
|
|
* A weston_output_color_outcome owns (a reference to) everything it contains.
|
|
|
|
*
|
|
|
|
* \ingroup output
|
|
|
|
* \internal
|
|
|
|
*/
|
|
|
|
struct weston_output_color_outcome {
|
|
|
|
/** sRGB to output color space transformation */
|
|
|
|
struct weston_color_transform *from_sRGB_to_output;
|
|
|
|
|
|
|
|
/** sRGB to blending color space transformation */
|
|
|
|
struct weston_color_transform *from_sRGB_to_blend;
|
|
|
|
|
|
|
|
/** Blending to output color space transformation */
|
|
|
|
struct weston_color_transform *from_blend_to_output;
|
|
|
|
|
|
|
|
/** HDR Static Metadata Type 1 for WESTON_EOTF_MODE_ST2084 */
|
|
|
|
struct weston_hdr_metadata_type1 hdr_meta;
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Content producer for heads
|
|
|
|
*
|
|
|
|
* \rst
|
|
|
|
See :ref:`libweston-output`. \endrst
|
|
|
|
*
|
|
|
|
* \ingroup output
|
|
|
|
*/
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
struct weston_output {
|
|
|
|
uint32_t id;
|
|
|
|
char *name;
|
|
|
|
|
|
|
|
/** Matches the lifetime from the user perspective */
|
|
|
|
struct wl_signal user_destroy_signal;
|
|
|
|
|
|
|
|
void *renderer_state;
|
|
|
|
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
struct wl_list link;
|
|
|
|
struct weston_compositor *compositor;
|
|
|
|
|
|
|
|
/* struct weston_paint_node::output_link */
|
|
|
|
struct wl_list paint_node_list;
|
|
|
|
|
|
|
|
/** From global to output buffer coordinates. */
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
struct weston_matrix matrix;
|
|
|
|
/** From output buffer to global coordinates. */
|
|
|
|
struct weston_matrix inverse_matrix;
|
|
|
|
|
|
|
|
struct wl_list animation_list;
|
|
|
|
int32_t x, y, width, height;
|
|
|
|
|
|
|
|
/** List of paint nodes in z-order, from top to bottom, maybe pruned
|
|
|
|
*
|
|
|
|
* struct weston_paint_node::z_order_link
|
|
|
|
*/
|
|
|
|
struct wl_list paint_node_z_order_list;
|
|
|
|
|
|
|
|
/** Output area in global coordinates, simple rect */
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
pixman_region32_t region;
|
|
|
|
|
|
|
|
/** True if damage has occurred since the last repaint for this output;
|
|
|
|
* if set, a repaint will eventually occur. */
|
|
|
|
bool repaint_needed;
|
|
|
|
|
|
|
|
/** Used only between repaint_begin and repaint_cancel. */
|
|
|
|
bool repainted;
|
|
|
|
|
|
|
|
/** State of the repaint loop */
|
|
|
|
enum {
|
|
|
|
REPAINT_NOT_SCHEDULED = 0, /**< idle; no repaint will occur */
|
|
|
|
REPAINT_BEGIN_FROM_IDLE, /**< start_repaint_loop scheduled */
|
|
|
|
REPAINT_SCHEDULED, /**< repaint is scheduled to occur */
|
|
|
|
REPAINT_AWAITING_COMPLETION, /**< last repaint not yet finished */
|
|
|
|
} repaint_status;
|
|
|
|
|
|
|
|
/** If repaint_status is REPAINT_SCHEDULED, contains the time the
|
|
|
|
* next repaint should be run */
|
|
|
|
struct timespec next_repaint;
|
|
|
|
|
|
|
|
/** For cancelling the idle_repaint callback on output destruction. */
|
|
|
|
struct wl_event_source *idle_repaint_source;
|
|
|
|
|
|
|
|
int dirty;
|
|
|
|
struct wl_signal frame_signal;
|
|
|
|
struct wl_signal destroy_signal; /**< sent when disabled */
|
|
|
|
int move_x, move_y;
|
|
|
|
struct timespec frame_time; /* presentation timestamp */
|
|
|
|
uint64_t msc; /* media stream counter */
|
|
|
|
int disable_planes;
|
|
|
|
int destroying;
|
|
|
|
struct wl_list feedback_list;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
|
|
|
uint32_t transform;
|
|
|
|
int32_t native_scale;
|
|
|
|
int32_t current_scale;
|
|
|
|
int32_t original_scale;
|
|
|
|
|
|
|
|
struct weston_mode *native_mode;
|
|
|
|
struct weston_mode *current_mode;
|
|
|
|
struct weston_mode *original_mode;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
struct wl_list mode_list;
|
|
|
|
|
|
|
|
struct wl_list head_list; /**< List of driven weston_heads */
|
|
|
|
|
|
|
|
enum weston_hdcp_protection desired_protection;
|
|
|
|
enum weston_hdcp_protection current_protection;
|
|
|
|
bool allow_protection;
|
|
|
|
|
|
|
|
int (*start_repaint_loop)(struct weston_output *output);
|
compositor: remove repaint_data from compositor
The repaint_data is entirely backend specific. Moreover, it is only used by the
drm backend, while other backends ignore the repaint data.
There will always be only one repaint active, thus, there is no need to pass the
repaint data from the outside.
The repaint_data breaks with the multi-backend series, which calls repaint begin
for all backends to get the repaint_data. The repaint_data of the last backend
will then be passed to all other backend. At the moment, this works, because the
drm backend is the only backend that implements the begin_repaint call.
Another option would be to track the repaint data per backend in the compositor,
but actually, it the backend needs to track state across the calls, it's its own
responsibility.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
3 years ago
|
|
|
int (*repaint)(struct weston_output *output, pixman_region32_t *damage);
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
void (*destroy)(struct weston_output *output);
|
compositor: remove repaint_data from compositor
The repaint_data is entirely backend specific. Moreover, it is only used by the
drm backend, while other backends ignore the repaint data.
There will always be only one repaint active, thus, there is no need to pass the
repaint data from the outside.
The repaint_data breaks with the multi-backend series, which calls repaint begin
for all backends to get the repaint_data. The repaint_data of the last backend
will then be passed to all other backend. At the moment, this works, because the
drm backend is the only backend that implements the begin_repaint call.
Another option would be to track the repaint data per backend in the compositor,
but actually, it the backend needs to track state across the calls, it's its own
responsibility.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
3 years ago
|
|
|
void (*assign_planes)(struct weston_output *output);
|
|
|
|
int (*switch_mode)(struct weston_output *output, struct weston_mode *mode);
|
|
|
|
|
|
|
|
/* backlight values are on 0-255 range, where higher is brighter */
|
|
|
|
int32_t backlight_current;
|
|
|
|
void (*set_backlight)(struct weston_output *output, uint32_t value);
|
|
|
|
void (*set_dpms)(struct weston_output *output, enum dpms_enum level);
|
|
|
|
|
|
|
|
uint16_t gamma_size;
|
|
|
|
void (*set_gamma)(struct weston_output *output,
|
|
|
|
uint16_t size,
|
|
|
|
uint16_t *r,
|
|
|
|
uint16_t *g,
|
|
|
|
uint16_t *b);
|
compositor: Implement JSON-timeline logging
Logging is activated and deactivated with the debug key binding 't'.
When activated, it creates a new log file, where it records the events.
The log file contains events and detailed object information entries in
JSON format, and is meant to be parsed in sequence from beginning to the
end.
The emitted events are mostly related to the output repaint cycle, like
when repaint begins, is submitted to GPU, and when it completes on a
vblank. This is recorded per-output. Also some per-surface events are
recorded, including when surface damage is flushed.
To reduce the log size, events refer to objects like outputs and
surfaces by id numbers. Detailed object information is emitted only as
needed: on the first object occurrence, and afterwards only if
weston_timeline_object::force_refresh asks for it.
The detailed information for surfaces includes the string returned by
weston_surface::get_label. Therefore it is important to set
weston_timeline_object::force_refresh = 1 whenever the string would
change, so that the new details get recorded.
A rudimentary parser and SVG generator can be found at:
https://github.com/ppaalanen/wesgr
The timeline logs can answer questions including:
- How does the compositor repaint cycle work timing-wise?
- When was the vblank deadline missed?
- What is the latency from surface commit to showing the new content on
screen?
- How long does it take to process the scenegraph?
v2: weston_surface::get_description renamed to get_label.
v3: reafctor a bit into fprint_quoted_string().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
10 years ago
|
|
|
|
|
|
|
bool enabled; /**< is in the output_list, not pending list */
|
|
|
|
int scale;
|
|
|
|
|
|
|
|
struct weston_color_profile *color_profile;
|
|
|
|
bool from_blend_to_output_by_backend;
|
|
|
|
enum weston_eotf_mode eotf_mode;
|
|
|
|
struct weston_color_characteristics color_characteristics;
|
|
|
|
|
|
|
|
struct weston_output_color_outcome *color_outcome;
|
|
|
|
uint64_t color_outcome_serial;
|
|
|
|
|
|
|
|
int (*enable)(struct weston_output *output);
|
|
|
|
int (*disable)(struct weston_output *output);
|
|
|
|
|
|
|
|
/** Attach a head in the backend
|
|
|
|
*
|
|
|
|
* @param output The output to attach to.
|
|
|
|
* @param head The head to attach.
|
|
|
|
* @return 0 on success, -1 on failure.
|
|
|
|
*
|
|
|
|
* Do anything necessary to account for a new head being attached to
|
|
|
|
* the output, and check any conditions possible. On failure, both
|
|
|
|
* the head and the output must be left as before the call.
|
|
|
|
*
|
|
|
|
* Libweston core will add the head to the head_list after a successful
|
|
|
|
* call.
|
|
|
|
*/
|
|
|
|
int (*attach_head)(struct weston_output *output,
|
|
|
|
struct weston_head *head);
|
|
|
|
|
|
|
|
/** Detach a head in the backend
|
|
|
|
*
|
|
|
|
* @param output The output to detach from.
|
|
|
|
* @param head The head to detach.
|
|
|
|
*
|
|
|
|
* Do any clean-up necessary to detach this head from the output.
|
|
|
|
* The head has already been removed from the output's head_list.
|
|
|
|
*/
|
|
|
|
void (*detach_head)(struct weston_output *output,
|
|
|
|
struct weston_head *head);
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
};
|
|
|
|
|
|
|
|
enum weston_pointer_motion_mask {
|
|
|
|
WESTON_POINTER_MOTION_ABS = 1 << 0,
|
|
|
|
WESTON_POINTER_MOTION_REL = 1 << 1,
|
|
|
|
WESTON_POINTER_MOTION_REL_UNACCEL = 1 << 2,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_pointer_motion_event {
|
|
|
|
uint32_t mask;
|
|
|
|
struct timespec time;
|
|
|
|
double x;
|
|
|
|
double y;
|
|
|
|
double dx;
|
|
|
|
double dy;
|
|
|
|
double dx_unaccel;
|
|
|
|
double dy_unaccel;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_pointer_axis_event {
|
|
|
|
uint32_t axis;
|
|
|
|
double value;
|
|
|
|
bool has_discrete;
|
|
|
|
int32_t discrete;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_pointer_grab;
|
|
|
|
struct weston_pointer_grab_interface {
|
|
|
|
void (*focus)(struct weston_pointer_grab *grab);
|
|
|
|
void (*motion)(struct weston_pointer_grab *grab,
|
|
|
|
const struct timespec *time,
|
|
|
|
struct weston_pointer_motion_event *event);
|
|
|
|
void (*button)(struct weston_pointer_grab *grab,
|
|
|
|
const struct timespec *time,
|
|
|
|
uint32_t button, uint32_t state);
|
|
|
|
void (*axis)(struct weston_pointer_grab *grab,
|
|
|
|
const struct timespec *time,
|
|
|
|
struct weston_pointer_axis_event *event);
|
|
|
|
void (*axis_source)(struct weston_pointer_grab *grab, uint32_t source);
|
|
|
|
void (*frame)(struct weston_pointer_grab *grab);
|
|
|
|
void (*cancel)(struct weston_pointer_grab *grab);
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_pointer_grab {
|
|
|
|
const struct weston_pointer_grab_interface *interface;
|
|
|
|
struct weston_pointer *pointer;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_keyboard_grab;
|
|
|
|
struct weston_keyboard_grab_interface {
|
|
|
|
void (*key)(struct weston_keyboard_grab *grab,
|
|
|
|
const struct timespec *time, uint32_t key, uint32_t state);
|
|
|
|
void (*modifiers)(struct weston_keyboard_grab *grab, uint32_t serial,
|
|
|
|
uint32_t mods_depressed, uint32_t mods_latched,
|
|
|
|
uint32_t mods_locked, uint32_t group);
|
|
|
|
void (*cancel)(struct weston_keyboard_grab *grab);
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_keyboard_grab {
|
|
|
|
const struct weston_keyboard_grab_interface *interface;
|
|
|
|
struct weston_keyboard *keyboard;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_touch_grab;
|
|
|
|
struct weston_touch_grab_interface {
|
|
|
|
void (*down)(struct weston_touch_grab *grab,
|
|
|
|
const struct timespec *time,
|
|
|
|
int touch_id,
|
|
|
|
wl_fixed_t sx,
|
|
|
|
wl_fixed_t sy);
|
|
|
|
void (*up)(struct weston_touch_grab *grab,
|
|
|
|
const struct timespec *time,
|
|
|
|
int touch_id);
|
|
|
|
void (*motion)(struct weston_touch_grab *grab,
|
|
|
|
const struct timespec *time,
|
|
|
|
int touch_id,
|
|
|
|
wl_fixed_t sx,
|
|
|
|
wl_fixed_t sy);
|
|
|
|
void (*frame)(struct weston_touch_grab *grab);
|
|
|
|
void (*cancel)(struct weston_touch_grab *grab);
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_touch_grab {
|
|
|
|
const struct weston_touch_grab_interface *interface;
|
|
|
|
struct weston_touch *touch;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_data_offer {
|
|
|
|
struct wl_resource *resource;
|
|
|
|
struct weston_data_source *source;
|
|
|
|
struct wl_listener source_destroy_listener;
|
|
|
|
uint32_t dnd_actions;
|
|
|
|
enum wl_data_device_manager_dnd_action preferred_dnd_action;
|
|
|
|
bool in_ask;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_data_source {
|
|
|
|
struct wl_resource *resource;
|
|
|
|
struct wl_signal destroy_signal;
|
|
|
|
struct wl_array mime_types;
|
|
|
|
struct weston_data_offer *offer;
|
|
|
|
struct weston_seat *seat;
|
|
|
|
bool accepted;
|
|
|
|
bool actions_set;
|
|
|
|
bool set_selection;
|
|
|
|
uint32_t dnd_actions;
|
|
|
|
enum wl_data_device_manager_dnd_action current_dnd_action;
|
|
|
|
enum wl_data_device_manager_dnd_action compositor_action;
|
|
|
|
|
|
|
|
void (*accept)(struct weston_data_source *source,
|
|
|
|
uint32_t serial, const char *mime_type);
|
|
|
|
void (*send)(struct weston_data_source *source,
|
|
|
|
const char *mime_type, int32_t fd);
|
|
|
|
void (*cancel)(struct weston_data_source *source);
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_pointer_client {
|
|
|
|
struct wl_list link;
|
|
|
|
struct wl_client *client;
|
|
|
|
struct wl_list pointer_resources;
|
|
|
|
struct wl_list relative_pointer_resources;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_pointer {
|
|
|
|
struct weston_seat *seat;
|
|
|
|
|
|
|
|
struct wl_list pointer_clients;
|
|
|
|
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
struct weston_view *focus;
|
|
|
|
struct weston_pointer_client *focus_client;
|
|
|
|
uint32_t focus_serial;
|
|
|
|
struct wl_listener focus_view_listener;
|
|
|
|
struct wl_listener focus_resource_listener;
|
|
|
|
struct wl_signal focus_signal;
|
|
|
|
struct wl_signal motion_signal;
|
|
|
|
struct wl_signal destroy_signal;
|
|
|
|
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
struct weston_view *sprite;
|
|
|
|
struct wl_listener sprite_destroy_listener;
|
|
|
|
int32_t hotspot_x, hotspot_y;
|
|
|
|
|
|
|
|
struct weston_pointer_grab *grab;
|
|
|
|
struct weston_pointer_grab default_grab;
|
|
|
|
wl_fixed_t grab_x, grab_y;
|
|
|
|
uint32_t grab_button;
|
|
|
|
uint32_t grab_serial;
|
|
|
|
struct timespec grab_time;
|
|
|
|
|
|
|
|
wl_fixed_t x, y;
|
|
|
|
wl_fixed_t sx, sy;
|
|
|
|
uint32_t button_count;
|
|
|
|
|
|
|
|
struct wl_listener output_destroy_listener;
|
|
|
|
|
|
|
|
struct wl_list timestamps_list;
|
|
|
|
};
|
|
|
|
|
|
|
|
/** libinput style calibration matrix
|
|
|
|
*
|
|
|
|
* See https://wayland.freedesktop.org/libinput/doc/latest/absolute_axes.html
|
|
|
|
* and libinput_device_config_calibration_set_matrix().
|
|
|
|
*/
|
|
|
|
struct weston_touch_device_matrix {
|
|
|
|
float m[6];
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_touch_device;
|
|
|
|
|
|
|
|
/** Operations for a calibratable touchscreen */
|
|
|
|
struct weston_touch_device_ops {
|
|
|
|
/** Get the associated output if existing. */
|
|
|
|
struct weston_output *(*get_output)(struct weston_touch_device *device);
|
|
|
|
|
|
|
|
/** Get the name of the associated head if existing. */
|
|
|
|
const char *
|
|
|
|
(*get_calibration_head_name)(struct weston_touch_device *device);
|
|
|
|
|
|
|
|
/** Retrieve the current calibration matrix. */
|
|
|
|
void (*get_calibration)(struct weston_touch_device *device,
|
|
|
|
struct weston_touch_device_matrix *cal);
|
|
|
|
|
|
|
|
/** Set a new calibration matrix. */
|
|
|
|
void (*set_calibration)(struct weston_touch_device *device,
|
|
|
|
const struct weston_touch_device_matrix *cal);
|
|
|
|
};
|
|
|
|
|
input: introduce touch event mode for calibrator
In addition to the normal touch event processing mode, introduce a new
mode for calibrating a touchscreen input device.
In the calibration mode, normal touch event processing is skipped, and
the raw events are forwarded to the calibrator instead. The calibrator
is not yet implemented, so the calls will be added in a following patch.
To switch between modes, two functions are added, one for entering each
mode. The mode switch happens only when no touches are down on any touch
device, to avoid confusing touch grabs and clients. To realise this, the
state machine has four states: prepare and actual state for both normal
and calibrator modes.
At this point nothing will attempt to change the touch event mode.
The new calibrator mode is necessary, because when calibrating a
touchscreen, the touch events must be routed to the calibration client
directly. The touch coordinates are expected to be wrong, so they cannot
go through the normal focus surface picking. The calibrator code also
cannot use the normal touch grab interface, because it needs to be able
to distinguish between different physical touch input devices, even if
they are part of the same weston_seat. This requirement makes
calibration special enough to warrant the new mode, a sort of "super
grab".
Co-developed by Louis-Francis and Pekka.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
7 years ago
|
|
|
enum weston_touch_mode {
|
|
|
|
/** Normal touch event handling */
|
|
|
|
WESTON_TOUCH_MODE_NORMAL,
|
|
|
|
|
|
|
|
/** Prepare moving to WESTON_TOUCH_MODE_CALIB.
|
|
|
|
*
|
|
|
|
* Move to WESTON_TOUCH_MODE_CALIB as soon as no touches are down on
|
|
|
|
* any seat. Until then, all touch events are routed normally.
|
|
|
|
*/
|
|
|
|
WESTON_TOUCH_MODE_PREP_CALIB,
|
|
|
|
|
|
|
|
/** Calibration mode
|
|
|
|
*
|
|
|
|
* Only a single weston_touch_device forwards events to the calibrator
|
|
|
|
* all other touch device cause a calibrator "wrong device" event to
|
|
|
|
* be sent.
|
|
|
|
*/
|
|
|
|
WESTON_TOUCH_MODE_CALIB,
|
|
|
|
|
|
|
|
/** Prepare moving to WESTON_TOUCH_MODE_NORMAL.
|
|
|
|
*
|
|
|
|
* Move to WESTON_TOUCH_MODE_NORMAL as soon as no touches are down on
|
|
|
|
* any seat. Until then, touch events are routed as in
|
|
|
|
* WESTON_TOUCH_MODE_CALIB except "wrong device" events are not sent.
|
|
|
|
*/
|
|
|
|
WESTON_TOUCH_MODE_PREP_NORMAL
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Represents a physical touchscreen input device */
|
|
|
|
struct weston_touch_device {
|
|
|
|
char *syspath; /**< unique name */
|
|
|
|
|
|
|
|
struct weston_touch *aggregate; /**< weston_touch this is part of */
|
|
|
|
struct wl_list link; /**< in weston_touch::device_list */
|
|
|
|
struct wl_signal destroy_signal; /**< destroy notifier */
|
|
|
|
|
|
|
|
void *backend_data; /**< backend-specific private */
|
|
|
|
|
|
|
|
const struct weston_touch_device_ops *ops;
|
|
|
|
struct weston_touch_device_matrix saved_calibration;
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Represents a set of touchscreen devices aggregated under a seat */
|
|
|
|
struct weston_touch {
|
|
|
|
struct weston_seat *seat;
|
|
|
|
|
|
|
|
struct wl_list device_list; /* struct weston_touch_device::link */
|
|
|
|
|
|
|
|
struct wl_list resource_list;
|
|
|
|
struct wl_list focus_resource_list;
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
struct weston_view *focus;
|
|
|
|
struct wl_listener focus_view_listener;
|
|
|
|
struct wl_listener focus_resource_listener;
|
|
|
|
uint32_t focus_serial;
|
|
|
|
struct wl_signal focus_signal;
|
|
|
|
|
|
|
|
uint32_t num_tp;
|
|
|
|
|
|
|
|
struct weston_touch_grab *grab;
|
|
|
|
struct weston_touch_grab default_grab;
|
|
|
|
int grab_touch_id;
|
|
|
|
wl_fixed_t grab_x, grab_y;
|
|
|
|
uint32_t grab_serial;
|
|
|
|
struct timespec grab_time;
|
|
|
|
|
|
|
|
struct wl_list timestamps_list;
|
|
|
|
};
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_pointer_motion_to_abs(struct weston_pointer *pointer,
|
|
|
|
struct weston_pointer_motion_event *event,
|
|
|
|
wl_fixed_t *x, wl_fixed_t *y);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_pointer_send_motion(struct weston_pointer *pointer,
|
|
|
|
const struct timespec *time,
|
|
|
|
struct weston_pointer_motion_event *event);
|
|
|
|
bool
|
|
|
|
weston_pointer_has_focus_resource(struct weston_pointer *pointer);
|
|
|
|
void
|
|
|
|
weston_pointer_send_button(struct weston_pointer *pointer,
|
|
|
|
const struct timespec *time,
|
|
|
|
uint32_t button, uint32_t state_w);
|
|
|
|
void
|
|
|
|
weston_pointer_send_axis(struct weston_pointer *pointer,
|
|
|
|
const struct timespec *time,
|
|
|
|
struct weston_pointer_axis_event *event);
|
|
|
|
void
|
|
|
|
weston_pointer_send_axis_source(struct weston_pointer *pointer,
|
|
|
|
uint32_t source);
|
|
|
|
void
|
|
|
|
weston_pointer_send_frame(struct weston_pointer *pointer);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_pointer_set_focus(struct weston_pointer *pointer,
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
struct weston_view *view,
|
|
|
|
wl_fixed_t sx, wl_fixed_t sy);
|
|
|
|
void
|
|
|
|
weston_pointer_clear_focus(struct weston_pointer *pointer);
|
|
|
|
void
|
|
|
|
weston_pointer_start_grab(struct weston_pointer *pointer,
|
|
|
|
struct weston_pointer_grab *grab);
|
|
|
|
void
|
|
|
|
weston_pointer_end_grab(struct weston_pointer *pointer);
|
|
|
|
void
|
|
|
|
weston_pointer_move(struct weston_pointer *pointer,
|
|
|
|
struct weston_pointer_motion_event *event);
|
|
|
|
void
|
|
|
|
weston_keyboard_set_focus(struct weston_keyboard *keyboard,
|
|
|
|
struct weston_surface *surface);
|
|
|
|
void
|
|
|
|
weston_keyboard_start_grab(struct weston_keyboard *device,
|
|
|
|
struct weston_keyboard_grab *grab);
|
|
|
|
void
|
|
|
|
weston_keyboard_end_grab(struct weston_keyboard *keyboard);
|
|
|
|
int
|
|
|
|
/*
|
|
|
|
* 'mask' and 'value' should be a bitwise mask of one or more
|
|
|
|
* valued of the weston_keyboard_locks enum.
|
|
|
|
*/
|
|
|
|
weston_keyboard_set_locks(struct weston_keyboard *keyboard,
|
|
|
|
uint32_t mask, uint32_t value);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_keyboard_send_key(struct weston_keyboard *keyboard,
|
|
|
|
const struct timespec *time, uint32_t key,
|
|
|
|
enum wl_keyboard_key_state state);
|
|
|
|
void
|
|
|
|
weston_keyboard_send_modifiers(struct weston_keyboard *keyboard,
|
|
|
|
uint32_t serial, uint32_t mods_depressed,
|
|
|
|
uint32_t mods_latched,
|
|
|
|
uint32_t mods_locked, uint32_t group);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_touch_set_focus(struct weston_touch *touch,
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
struct weston_view *view);
|
|
|
|
void
|
|
|
|
weston_touch_start_grab(struct weston_touch *touch,
|
|
|
|
struct weston_touch_grab *grab);
|
|
|
|
void
|
|
|
|
weston_touch_end_grab(struct weston_touch *touch);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_touch_send_down(struct weston_touch *touch, const struct timespec *time,
|
|
|
|
int touch_id, wl_fixed_t x, wl_fixed_t y);
|
|
|
|
void
|
|
|
|
weston_touch_send_up(struct weston_touch *touch, const struct timespec *time,
|
|
|
|
int touch_id);
|
|
|
|
void
|
|
|
|
weston_touch_send_motion(struct weston_touch *touch,
|
|
|
|
const struct timespec *time, int touch_id,
|
|
|
|
wl_fixed_t x, wl_fixed_t y);
|
|
|
|
void
|
|
|
|
weston_touch_send_frame(struct weston_touch *touch);
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_seat_set_selection(struct weston_seat *seat,
|
|
|
|
struct weston_data_source *source, uint32_t serial);
|
|
|
|
|
|
|
|
int
|
|
|
|
weston_pointer_start_drag(struct weston_pointer *pointer,
|
|
|
|
struct weston_data_source *source,
|
|
|
|
struct weston_surface *icon,
|
|
|
|
struct wl_client *client);
|
|
|
|
struct weston_xkb_info {
|
|
|
|
struct xkb_keymap *keymap;
|
|
|
|
struct ro_anonymous_file *keymap_rofile;
|
|
|
|
int32_t ref_count;
|
|
|
|
xkb_mod_index_t shift_mod;
|
|
|
|
xkb_mod_index_t caps_mod;
|
|
|
|
xkb_mod_index_t ctrl_mod;
|
|
|
|
xkb_mod_index_t alt_mod;
|
|
|
|
xkb_mod_index_t mod2_mod;
|
|
|
|
xkb_mod_index_t mod3_mod;
|
|
|
|
xkb_mod_index_t super_mod;
|
|
|
|
xkb_mod_index_t mod5_mod;
|
|
|
|
xkb_led_index_t num_led;
|
|
|
|
xkb_led_index_t caps_led;
|
|
|
|
xkb_led_index_t scroll_led;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_keyboard {
|
|
|
|
struct weston_seat *seat;
|
|
|
|
|
|
|
|
struct wl_list resource_list;
|
|
|
|
struct wl_list focus_resource_list;
|
|
|
|
struct weston_surface *focus;
|
|
|
|
struct wl_listener focus_resource_listener;
|
|
|
|
uint32_t focus_serial;
|
|
|
|
struct wl_signal focus_signal;
|
|
|
|
|
|
|
|
struct weston_keyboard_grab *grab;
|
|
|
|
struct weston_keyboard_grab default_grab;
|
|
|
|
uint32_t grab_key;
|
|
|
|
uint32_t grab_serial;
|
|
|
|
struct timespec grab_time;
|
|
|
|
|
|
|
|
struct wl_array keys;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
uint32_t mods_depressed;
|
|
|
|
uint32_t mods_latched;
|
|
|
|
uint32_t mods_locked;
|
|
|
|
uint32_t group;
|
|
|
|
} modifiers;
|
|
|
|
|
|
|
|
struct weston_keyboard_grab input_method_grab;
|
|
|
|
struct wl_resource *input_method_resource;
|
|
|
|
|
|
|
|
struct weston_xkb_info *xkb_info;
|
|
|
|
struct {
|
|
|
|
struct xkb_state *state;
|
|
|
|
enum weston_led leds;
|
|
|
|
} xkb_state;
|
|
|
|
struct xkb_keymap *pending_keymap;
|
|
|
|
|
|
|
|
struct wl_list timestamps_list;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_seat {
|
|
|
|
struct wl_list base_resource_list;
|
|
|
|
|
|
|
|
struct wl_global *global;
|
|
|
|
struct weston_pointer *pointer_state;
|
|
|
|
struct weston_keyboard *keyboard_state;
|
|
|
|
struct weston_touch *touch_state;
|
|
|
|
int pointer_device_count;
|
|
|
|
int keyboard_device_count;
|
|
|
|
int touch_device_count;
|
|
|
|
|
|
|
|
struct weston_output *output; /* constraint */
|
|
|
|
|
|
|
|
struct wl_signal destroy_signal;
|
|
|
|
struct wl_signal updated_caps_signal;
|
|
|
|
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
struct weston_compositor *compositor;
|
|
|
|
struct wl_list link;
|
|
|
|
enum weston_keyboard_modifier modifier_state;
|
|
|
|
struct weston_surface *saved_kbd_focus;
|
|
|
|
struct wl_listener saved_kbd_focus_listener;
|
|
|
|
bool use_saved_kbd_focus;
|
|
|
|
struct wl_list drag_resource_list;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
|
|
|
uint32_t selection_serial;
|
|
|
|
struct weston_data_source *selection_data_source;
|
|
|
|
struct wl_listener selection_data_source_listener;
|
|
|
|
struct wl_signal selection_signal;
|
|
|
|
|
|
|
|
void (*led_update)(struct weston_seat *ws, enum weston_led leds);
|
|
|
|
|
|
|
|
struct input_method *input_method;
|
|
|
|
char *seat_name;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
WESTON_COMPOSITOR_ACTIVE, /* normal rendering and events */
|
|
|
|
WESTON_COMPOSITOR_IDLE, /* shell->unlock called on activity */
|
|
|
|
WESTON_COMPOSITOR_OFFSCREEN, /* no rendering, no frame events */
|
|
|
|
WESTON_COMPOSITOR_SLEEPING /* same as offscreen, but also set dpms
|
|
|
|
* to off */
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_layer_entry {
|
|
|
|
struct wl_list link;
|
|
|
|
struct weston_layer *layer;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Higher value means higher in the stack.
|
|
|
|
*
|
|
|
|
* These values are based on well-known concepts in a classic desktop
|
|
|
|
* environment. Third-party modules based on libweston are encouraged to use
|
|
|
|
* them to integrate better with other projects.
|
|
|
|
*
|
|
|
|
* A fully integrated environment can use any value, based on these or not,
|
|
|
|
* at their discretion.
|
|
|
|
*/
|
|
|
|
enum weston_layer_position {
|
|
|
|
/*
|
|
|
|
* Special value to make the layer invisible and still rendered.
|
|
|
|
* This is used by compositors wanting e.g. minimized surfaces to still
|
|
|
|
* receive frame callbacks.
|
|
|
|
*/
|
|
|
|
WESTON_LAYER_POSITION_HIDDEN = 0x00000000,
|
|
|
|
|
|
|
|
/*
|
|
|
|
* There should always be a background layer with a surface covering
|
|
|
|
* the visible area.
|
|
|
|
*
|
|
|
|
* If the compositor handles the background itself, it should use
|
|
|
|
* BACKGROUND.
|
|
|
|
*
|
|
|
|
* If the compositor supports runtime-loadable modules to set the
|
|
|
|
* background, it should put a solid color surface at (BACKGROUND - 1)
|
|
|
|
* and modules must use BACKGROUND.
|
|
|
|
*/
|
|
|
|
WESTON_LAYER_POSITION_BACKGROUND = 0x00000002,
|
|
|
|
|
|
|
|
/* For "desktop widgets" and applications like conky. */
|
|
|
|
WESTON_LAYER_POSITION_BOTTOM_UI = 0x30000000,
|
|
|
|
|
|
|
|
/* For regular applications, only one layer should have this value
|
|
|
|
* to ensure proper stacking control. */
|
|
|
|
WESTON_LAYER_POSITION_NORMAL = 0x50000000,
|
|
|
|
|
|
|
|
/* For desktop UI, like panels. */
|
|
|
|
WESTON_LAYER_POSITION_UI = 0x80000000,
|
|
|
|
|
|
|
|
/* For fullscreen applications that should cover UI. */
|
|
|
|
WESTON_LAYER_POSITION_FULLSCREEN = 0xb0000000,
|
|
|
|
|
|
|
|
/* For special UI like on-screen keyboard that fullscreen applications
|
|
|
|
* will need. */
|
|
|
|
WESTON_LAYER_POSITION_TOP_UI = 0xe0000000,
|
|
|
|
|
|
|
|
/* For the lock surface. */
|
|
|
|
WESTON_LAYER_POSITION_LOCK = 0xffff0000,
|
|
|
|
|
|
|
|
/* Values reserved for libweston internal usage */
|
|
|
|
WESTON_LAYER_POSITION_CURSOR = 0xfffffffe,
|
|
|
|
WESTON_LAYER_POSITION_FADE = 0xffffffff,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_layer {
|
|
|
|
struct weston_compositor *compositor;
|
|
|
|
struct wl_list link; /* weston_compositor::layer_list */
|
|
|
|
enum weston_layer_position position;
|
|
|
|
pixman_box32_t mask;
|
|
|
|
struct weston_layer_entry view_list;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_plane {
|
|
|
|
struct weston_compositor *compositor;
|
|
|
|
pixman_region32_t damage; /**< in global coords */
|
|
|
|
pixman_region32_t clip;
|
|
|
|
int32_t x, y;
|
|
|
|
struct wl_list link;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_drm_format_array;
|
|
|
|
|
|
|
|
enum weston_capability {
|
|
|
|
/* backend/renderer supports arbitrary rotation */
|
|
|
|
WESTON_CAP_ROTATION_ANY = 0x0001,
|
|
|
|
|
|
|
|
/* screencaptures need to be y-flipped */
|
|
|
|
WESTON_CAP_CAPTURE_YFLIP = 0x0002,
|
|
|
|
|
|
|
|
/* backend/renderer has a separate cursor plane */
|
|
|
|
WESTON_CAP_CURSOR_PLANE = 0x0004,
|
|
|
|
|
|
|
|
/* backend supports setting arbitrary resolutions */
|
|
|
|
WESTON_CAP_ARBITRARY_MODES = 0x0008,
|
|
|
|
|
|
|
|
/* renderer supports weston_view_set_mask() clipping */
|
|
|
|
WESTON_CAP_VIEW_CLIP_MASK = 0x0010,
|
libweston: Support zwp_surface_synchronization_v1.set_acquire_fence
Implement the set_acquire_fence request of the
zwp_surface_synchronization_v1 interface.
The implementation uses the acquire fence in two ways:
1. If the associated buffer is used as GL render source, an
EGLSyncKHR is created from the fence and used to synchronize
access.
2. If the associated buffer is used as a plane framebuffer,
the acquire fence is treated as an in-fence for the atomic
commit operation. If in-fences are not supported and the buffer
has an acquire fence, we don't consider it for plane placement.
If the used compositor/renderer doesn't support explicit
synchronization, we don't advertise the protocol at all. Currently only
the DRM and X11 backends when using the GL renderer advertise the
protocol for production use.
Issues for discussion
---------------------
a. Currently, a server-side wait of EGLSyncKHR is performed before
using the EGLImage/texture during rendering. Unfortunately, it's not clear
from the specs whether this is generally safe to do, or we need to
sync before glEGLImageTargetTexture2DOES. The exception is
TEXTURE_EXTERNAL_OES where the spec mentions it's enough to sync
and then glBindTexture for any changes to take effect.
Changes in v5:
- Meson support.
- Make explicit sync server error reporting more generic, supporting
all explicit sync related interfaces not just
wp_linux_surface_synchronization.
- Fix typo in warning for missing EGL_KHR_wait_sync extension.
- Support minor version 2 of the explicit sync protocol (i.e., support
fences for opaque EGL buffers).
Changes in v4:
- Introduce and use fd_clear and and fd_move helpers.
- Don't check for a valid buffer when updating surface acquire fence fd
from state.
- Assert that pending state acquire fence fd is always clear
after a commit.
- Clarify that WESTON_CAP_EXPLICIT_SYNC applies to just the
renderer.
- Check for EGL_KHR_wait_sync before using eglWaitSyncKHR.
- Dup the acquire fence before passing to EGL.
Changes in v3:
- Keep acquire_fence_fd in surface instead of buffer.
- Clarify that WESTON_CAP_EXPLICIT_SYNC applies to both backend and
renderer.
- Move comment about non-ownership of in_fence_fd to struct
drm_plane_state definition.
- Assert that we don't try to use planes with in-fences when using the
legacy KMS API.
- Remove unnecessary info from wayland error messages.
- Handle acquire fence for subsurface commits.
- Guard against self-update in fd_update.
- Disconnect the client if acquire fence EGLSyncKHR creation or wait
fails.
- Use updated protocol interface names.
- User correct format specifier for resource ids.
- Advertise protocol for X11 backend with GL renderer.
Changes in v2:
- Remove sync file wait fallbacks.
- Raise UNSUPPORTED_BUFFER error at commit if we have an acquire
fence, but the committed buffer is not a valid linux_dmabuf.
- Don't put buffers with in-fences on planes that don't support
in-fences.
- Don't advertise explicit sync protocol if backend does not
support explicit sync.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
6 years ago
|
|
|
|
|
|
|
/* renderer supports explicit synchronization */
|
|
|
|
WESTON_CAP_EXPLICIT_SYNC = 0x0020,
|
|
|
|
|
|
|
|
/* renderer supports color management operations */
|
|
|
|
WESTON_CAP_COLOR_OPS = 0x0040,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Configuration struct for a backend.
|
|
|
|
*
|
|
|
|
* This struct carries the configuration for a backend, and it's
|
|
|
|
* passed to the backend's init entry point. The backend will
|
|
|
|
* likely want to subclass this in order to handle backend specific
|
|
|
|
* data.
|
|
|
|
*
|
|
|
|
* \rststar
|
|
|
|
* .. note:
|
|
|
|
*
|
|
|
|
* Alternate designs were proposed (Feb 2016) for using opaque structures[1]
|
|
|
|
* and for section+key/value getter/setters[2]. The rationale for selecting
|
|
|
|
* the transparent structure design is based on several assumptions[3] which
|
|
|
|
* may require re-evaluating the design choice if they fail to hold.
|
|
|
|
*
|
|
|
|
* 1. https://lists.freedesktop.org/archives/wayland-devel/2016-February/026989.html
|
|
|
|
* 2. https://lists.freedesktop.org/archives/wayland-devel/2016-February/026929.html
|
|
|
|
* 3. https://lists.freedesktop.org/archives/wayland-devel/2016-February/027228.html
|
|
|
|
*
|
|
|
|
* \endrststar
|
|
|
|
*/
|
|
|
|
struct weston_backend_config {
|
|
|
|
/** Major version for the backend-specific config struct
|
|
|
|
*
|
|
|
|
* This version must match exactly what the backend expects, otherwise
|
|
|
|
* the struct is incompatible.
|
|
|
|
*/
|
|
|
|
uint32_t struct_version;
|
|
|
|
|
|
|
|
/** Minor version of the backend-specific config struct
|
|
|
|
*
|
|
|
|
* This must be set to sizeof(struct backend-specific config).
|
|
|
|
* If the value here is smaller than what the backend expects, the
|
|
|
|
* extra config members will assume their default values.
|
|
|
|
*
|
|
|
|
* A value greater than what the backend expects is incompatible.
|
|
|
|
*/
|
|
|
|
size_t struct_size;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_backend;
|
|
|
|
|
|
|
|
/** Callback for saving calibration
|
|
|
|
*
|
|
|
|
* \param compositor The compositor.
|
|
|
|
* \param device The physical touch device to save for.
|
|
|
|
* \param calibration The new calibration from a client.
|
|
|
|
* \return -1 on failure, 0 on success.
|
|
|
|
*
|
|
|
|
* Failure will prevent taking the new calibration into use.
|
|
|
|
*/
|
|
|
|
typedef int (*weston_touch_calibration_save_func)(
|
|
|
|
struct weston_compositor *compositor,
|
|
|
|
struct weston_touch_device *device,
|
|
|
|
const struct weston_touch_device_matrix *calibration);
|
|
|
|
struct weston_touch_calibrator;
|
|
|
|
|
|
|
|
struct weston_desktop_xwayland;
|
|
|
|
struct weston_desktop_xwayland_interface;
|
|
|
|
struct weston_debug_compositor;
|
libweston: introduce CMS component architecture
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/467#note_814985
This starts building the framework required for implementing color
management.
The main new interface is struct weston_color_manager. This commit also
adds a no-op color manager implementation, which is used if no other
color manager is loaded. This no-op color manager simply provides
identity color transforms for everything, so that Weston keeps running
exactly like before.
weston_color_manager interface is incomplete and will be extended later.
Colorspace objects are not introduced in this commit. However, when
client content colorspace and output colorspace definitions are
combined, they will produce color transformations from client content to
output blending space and from output blending space to output space.
This commit introduces a placeholder struct for color transforms,
weston_color_transform. Objects of this type are expected to be heavy to
create and store, which is why they are designed to be shared as much as
possible, ideally making their instances unique. As color transform
description is intended to be generic in libweston core, renderers and
backends are expected to derive their own state for each transform
object as necessary. Creating and storing the derived state maybe be
expensive as well, more the reason to re-use these objects as much as
possible. E.g. GL-renderer might upload a 3D LUT into a texture and keep
the texture around. DRM-backend might create a KMS blob for a LUT and
keep that around.
As a color transform depends on both the surface and the output, a
transform object may need to be created for each unique pair of them.
Therefore color transforms are referenced from weston_paint_node. As
paint nodes exist for not just surface+output but surface+view+output
triplets, the code ensures that all paint nodes (having different view)
for the same surface+output have the same color transform state.
As a special case, if weston_color_transform is NULL, it means identity
transform. This short-circuits some checks and memory allocations, but
it does mean we use a separate member on weston_paint_node to know if
the color transform has been initialized or not.
Color transformations are pre-created at the weston_output
paint_node_z_order_list creation step. Currently the z order lists
contain all views globally, which means we populate color transforms we
may never need, e.g. a view is never shown on a particular output.
This problem should get fixed naturally when z order lists are
constructed "pruned" in the future: to contain only those paint nodes
that actually contribute to the output's image.
As nothing actually supports color transforms yet, both renderers and
the DRM-backend assert that they only get identity transforms. This
check has the side-effect that all surface-output pairs actually get a
weston_surface_color_transform_ref even though it points to NULL
weston_color_transform.
This design is inspired by Sebastian Wick's Weston color management
work.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
4 years ago
|
|
|
struct weston_color_manager;
|
|
|
|
struct weston_dmabuf_feedback;
|
|
|
|
struct weston_dmabuf_feedback_format_table;
|
|
|
|
|
|
|
|
/** Main object, container-like structure which aggregates all other objects.
|
|
|
|
*
|
|
|
|
* \ingroup compositor
|
|
|
|
*/
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
struct weston_compositor {
|
|
|
|
struct wl_signal destroy_signal;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
|
|
|
struct wl_display *wl_display;
|
|
|
|
struct weston_desktop_xwayland *xwayland;
|
|
|
|
const struct weston_desktop_xwayland_interface *xwayland_interface;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
|
|
|
/* surface signals */
|
|
|
|
struct wl_signal create_surface_signal;
|
|
|
|
struct wl_signal activate_signal;
|
|
|
|
struct wl_signal transform_signal;
|
|
|
|
|
|
|
|
struct wl_signal kill_signal;
|
|
|
|
struct wl_signal idle_signal;
|
|
|
|
struct wl_signal wake_signal;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
|
|
|
struct wl_signal show_input_panel_signal;
|
|
|
|
struct wl_signal hide_input_panel_signal;
|
|
|
|
struct wl_signal update_input_panel_signal;
|
|
|
|
|
|
|
|
struct wl_signal seat_created_signal;
|
|
|
|
struct wl_signal output_created_signal;
|
|
|
|
struct wl_signal output_destroyed_signal;
|
|
|
|
struct wl_signal output_moved_signal;
|
|
|
|
struct wl_signal output_resized_signal; /* callback argument: resized output */
|
|
|
|
|
|
|
|
/* Signal for output changes triggered by configuration from frontend
|
|
|
|
* or head state changes from backend.
|
|
|
|
*/
|
|
|
|
struct wl_signal output_heads_changed_signal; /* arg: weston_output */
|
|
|
|
|
|
|
|
struct wl_signal session_signal;
|
|
|
|
bool session_active;
|
|
|
|
|
|
|
|
struct weston_layer fade_layer;
|
|
|
|
struct weston_layer cursor_layer;
|
|
|
|
|
|
|
|
struct wl_list pending_output_list;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
struct wl_list output_list;
|
|
|
|
struct wl_list head_list; /* struct weston_head::compositor_link */
|
|
|
|
struct wl_list seat_list;
|
|
|
|
struct wl_list layer_list; /* struct weston_layer::link */
|
|
|
|
struct wl_list view_list; /* struct weston_view::link */
|
|
|
|
struct wl_list plane_list;
|
|
|
|
struct wl_list key_binding_list;
|
|
|
|
struct wl_list modifier_binding_list;
|
|
|
|
struct wl_list button_binding_list;
|
|
|
|
struct wl_list touch_binding_list;
|
|
|
|
struct wl_list axis_binding_list;
|
|
|
|
struct wl_list debug_binding_list;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
|
|
|
uint32_t state;
|
|
|
|
struct wl_event_source *idle_source;
|
|
|
|
uint32_t idle_inhibit;
|
|
|
|
int idle_time; /* timeout, s */
|
|
|
|
struct wl_event_source *repaint_timer;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
|
|
|
const struct weston_pointer_grab_interface *default_pointer_grab;
|
|
|
|
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
/* Repaint state. */
|
|
|
|
struct weston_plane primary_plane;
|
|
|
|
uint32_t capabilities; /* combination of enum weston_capability */
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
libweston: introduce CMS component architecture
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/467#note_814985
This starts building the framework required for implementing color
management.
The main new interface is struct weston_color_manager. This commit also
adds a no-op color manager implementation, which is used if no other
color manager is loaded. This no-op color manager simply provides
identity color transforms for everything, so that Weston keeps running
exactly like before.
weston_color_manager interface is incomplete and will be extended later.
Colorspace objects are not introduced in this commit. However, when
client content colorspace and output colorspace definitions are
combined, they will produce color transformations from client content to
output blending space and from output blending space to output space.
This commit introduces a placeholder struct for color transforms,
weston_color_transform. Objects of this type are expected to be heavy to
create and store, which is why they are designed to be shared as much as
possible, ideally making their instances unique. As color transform
description is intended to be generic in libweston core, renderers and
backends are expected to derive their own state for each transform
object as necessary. Creating and storing the derived state maybe be
expensive as well, more the reason to re-use these objects as much as
possible. E.g. GL-renderer might upload a 3D LUT into a texture and keep
the texture around. DRM-backend might create a KMS blob for a LUT and
keep that around.
As a color transform depends on both the surface and the output, a
transform object may need to be created for each unique pair of them.
Therefore color transforms are referenced from weston_paint_node. As
paint nodes exist for not just surface+output but surface+view+output
triplets, the code ensures that all paint nodes (having different view)
for the same surface+output have the same color transform state.
As a special case, if weston_color_transform is NULL, it means identity
transform. This short-circuits some checks and memory allocations, but
it does mean we use a separate member on weston_paint_node to know if
the color transform has been initialized or not.
Color transformations are pre-created at the weston_output
paint_node_z_order_list creation step. Currently the z order lists
contain all views globally, which means we populate color transforms we
may never need, e.g. a view is never shown on a particular output.
This problem should get fixed naturally when z order lists are
constructed "pruned" in the future: to contain only those paint nodes
that actually contribute to the output's image.
As nothing actually supports color transforms yet, both renderers and
the DRM-backend assert that they only get identity transforms. This
check has the side-effect that all surface-output pairs actually get a
weston_surface_color_transform_ref even though it points to NULL
weston_color_transform.
This design is inspired by Sebastian Wick's Weston color management
work.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
4 years ago
|
|
|
struct weston_color_manager *color_manager;
|
|
|
|
struct weston_renderer *renderer;
|
|
|
|
pixman_format_code_t read_format;
|
|
|
|
|
|
|
|
struct weston_backend *backend;
|
|
|
|
struct weston_launcher *launcher;
|
|
|
|
|
|
|
|
struct weston_dmabuf_feedback *default_dmabuf_feedback;
|
|
|
|
struct weston_dmabuf_feedback_format_table *dmabuf_feedback_format_table;
|
|
|
|
|
|
|
|
struct wl_list plugin_api_list; /* struct weston_plugin_api::link */
|
|
|
|
|
|
|
|
uint32_t output_id_pool;
|
|
|
|
|
|
|
|
struct xkb_rule_names xkb_names;
|
|
|
|
struct xkb_context *xkb_context;
|
|
|
|
struct weston_xkb_info *xkb_info;
|
|
|
|
|
|
|
|
int32_t kb_repeat_rate;
|
|
|
|
int32_t kb_repeat_delay;
|
|
|
|
|
|
|
|
bool vt_switching;
|
|
|
|
|
|
|
|
clockid_t presentation_clock;
|
|
|
|
int32_t repaint_msec;
|
|
|
|
struct timespec last_repaint_start;
|
|
|
|
|
|
|
|
unsigned int activate_serial;
|
|
|
|
|
|
|
|
struct wl_global *pointer_constraints;
|
|
|
|
|
|
|
|
int exit_code;
|
|
|
|
|
|
|
|
void *user_data;
|
|
|
|
void (*exit)(struct weston_compositor *c);
|
|
|
|
|
|
|
|
/* Whether to let the compositor run without any input device. */
|
|
|
|
bool require_input;
|
|
|
|
|
|
|
|
/* Test suite data */
|
|
|
|
struct weston_testsuite_data test_data;
|
|
|
|
|
|
|
|
/* Signal for a backend to inform a frontend about possible changes
|
|
|
|
* in head status.
|
|
|
|
*/
|
|
|
|
struct wl_signal heads_changed_signal;
|
|
|
|
struct wl_event_source *heads_changed_source;
|
input: introduce touch event mode for calibrator
In addition to the normal touch event processing mode, introduce a new
mode for calibrating a touchscreen input device.
In the calibration mode, normal touch event processing is skipped, and
the raw events are forwarded to the calibrator instead. The calibrator
is not yet implemented, so the calls will be added in a following patch.
To switch between modes, two functions are added, one for entering each
mode. The mode switch happens only when no touches are down on any touch
device, to avoid confusing touch grabs and clients. To realise this, the
state machine has four states: prepare and actual state for both normal
and calibrator modes.
At this point nothing will attempt to change the touch event mode.
The new calibrator mode is necessary, because when calibrating a
touchscreen, the touch events must be routed to the calibration client
directly. The touch coordinates are expected to be wrong, so they cannot
go through the normal focus surface picking. The calibrator code also
cannot use the normal touch grab interface, because it needs to be able
to distinguish between different physical touch input devices, even if
they are part of the same weston_seat. This requirement makes
calibration special enough to warrant the new mode, a sort of "super
grab".
Co-developed by Louis-Francis and Pekka.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
7 years ago
|
|
|
|
|
|
|
/* Touchscreen calibrator support: */
|
input: introduce touch event mode for calibrator
In addition to the normal touch event processing mode, introduce a new
mode for calibrating a touchscreen input device.
In the calibration mode, normal touch event processing is skipped, and
the raw events are forwarded to the calibrator instead. The calibrator
is not yet implemented, so the calls will be added in a following patch.
To switch between modes, two functions are added, one for entering each
mode. The mode switch happens only when no touches are down on any touch
device, to avoid confusing touch grabs and clients. To realise this, the
state machine has four states: prepare and actual state for both normal
and calibrator modes.
At this point nothing will attempt to change the touch event mode.
The new calibrator mode is necessary, because when calibrating a
touchscreen, the touch events must be routed to the calibration client
directly. The touch coordinates are expected to be wrong, so they cannot
go through the normal focus surface picking. The calibrator code also
cannot use the normal touch grab interface, because it needs to be able
to distinguish between different physical touch input devices, even if
they are part of the same weston_seat. This requirement makes
calibration special enough to warrant the new mode, a sort of "super
grab".
Co-developed by Louis-Francis and Pekka.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
7 years ago
|
|
|
enum weston_touch_mode touch_mode;
|
|
|
|
struct wl_global *touch_calibration;
|
|
|
|
weston_touch_calibration_save_func touch_calibration_save;
|
|
|
|
struct weston_layer calibrator_layer;
|
|
|
|
struct weston_touch_calibrator *touch_calibrator;
|
|
|
|
|
|
|
|
struct weston_log_context *weston_log_ctx;
|
|
|
|
struct weston_log_scope *debug_scene;
|
|
|
|
struct weston_log_scope *timeline;
|
|
|
|
struct weston_log_scope *libseat_debug;
|
|
|
|
|
|
|
|
struct content_protection *content_protection;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_buffer {
|
|
|
|
struct wl_resource *resource;
|
|
|
|
struct wl_signal destroy_signal;
|
|
|
|
struct wl_listener destroy_listener;
|
|
|
|
|
|
|
|
enum {
|
|
|
|
WESTON_BUFFER_SHM,
|
|
|
|
WESTON_BUFFER_DMABUF,
|
|
|
|
WESTON_BUFFER_RENDERER_OPAQUE,
|
|
|
|
WESTON_BUFFER_SOLID,
|
|
|
|
} type;
|
|
|
|
|
|
|
|
union {
|
|
|
|
struct wl_shm_buffer *shm_buffer;
|
|
|
|
void *dmabuf;
|
|
|
|
void *legacy_buffer;
|
|
|
|
struct {
|
|
|
|
float r, g, b, a;
|
|
|
|
} solid;
|
|
|
|
};
|
|
|
|
|
|
|
|
int32_t width, height;
|
|
|
|
uint32_t busy_count;
|
|
|
|
uint32_t passive_count;
|
|
|
|
enum {
|
|
|
|
ORIGIN_TOP_LEFT, /* buffer content starts at (0,0) */
|
|
|
|
ORIGIN_BOTTOM_LEFT, /* buffer content starts at (0, height) */
|
|
|
|
} buffer_origin;
|
|
|
|
bool direct_display;
|
|
|
|
|
|
|
|
void *renderer_private;
|
|
|
|
void *backend_private;
|
|
|
|
|
|
|
|
const struct pixel_format_info *pixel_format;
|
|
|
|
uint64_t format_modifier;
|
|
|
|
};
|
|
|
|
|
|
|
|
enum weston_buffer_reference_type {
|
|
|
|
BUFFER_REF_NONE,
|
|
|
|
BUFFER_MAY_BE_ACCESSED,
|
|
|
|
BUFFER_WILL_NOT_BE_ACCESSED,
|
|
|
|
};
|
|
|
|
|
compositor: introduce weston_buffer_reference
The wl_buffer reference counting API has been inconsistent. You would
manually increment the refcount and register a destroy listener, as
opposed to calling weston_buffer_post_release(), which internally
decremented the refcount, and then removing a list item.
Replace both cases with a single function:
weston_buffer_reference(weston_buffer_reference *ref, wl_buffer *buffer)
Buffer is assigned to ref->buffer, while taking care of all the refcounting
and release posting. You take a reference by passing a non-NULL buffer, and
release a reference by passing NULL as buffer. The function uses an
internal wl_buffer destroy listener, so the pointer gets reset on
destruction automatically.
This is inspired by the pipe_resource_reference() of Mesa, and modified
by krh's suggestion to add struct weston_buffer_reference.
Additionally, when a surface gets destroyed, the associated wl_buffer
will send a release event. Often the buffer is already destroyed on
client side, so the event will be discarded by libwayland-client.
Compositor-drm.c is converted to use weston_buffer_reference.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
12 years ago
|
|
|
struct weston_buffer_reference {
|
|
|
|
struct weston_buffer *buffer;
|
|
|
|
enum weston_buffer_reference_type type;
|
compositor: introduce weston_buffer_reference
The wl_buffer reference counting API has been inconsistent. You would
manually increment the refcount and register a destroy listener, as
opposed to calling weston_buffer_post_release(), which internally
decremented the refcount, and then removing a list item.
Replace both cases with a single function:
weston_buffer_reference(weston_buffer_reference *ref, wl_buffer *buffer)
Buffer is assigned to ref->buffer, while taking care of all the refcounting
and release posting. You take a reference by passing a non-NULL buffer, and
release a reference by passing NULL as buffer. The function uses an
internal wl_buffer destroy listener, so the pointer gets reset on
destruction automatically.
This is inspired by the pipe_resource_reference() of Mesa, and modified
by krh's suggestion to add struct weston_buffer_reference.
Additionally, when a surface gets destroyed, the associated wl_buffer
will send a release event. Often the buffer is already destroyed on
client side, so the event will be discarded by libwayland-client.
Compositor-drm.c is converted to use weston_buffer_reference.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
12 years ago
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_buffer_viewport {
|
|
|
|
struct {
|
|
|
|
/* wl_surface.set_buffer_transform */
|
|
|
|
uint32_t transform;
|
|
|
|
|
|
|
|
/* wl_surface.set_scaling_factor */
|
|
|
|
int32_t scale;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If src_width != wl_fixed_from_int(-1),
|
|
|
|
* then and only then src_* are used.
|
|
|
|
*/
|
|
|
|
wl_fixed_t src_x, src_y;
|
|
|
|
wl_fixed_t src_width, src_height;
|
|
|
|
} buffer;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
/*
|
|
|
|
* If width == -1, the size is inferred from the buffer.
|
|
|
|
*/
|
|
|
|
int32_t width, height;
|
|
|
|
} surface;
|
|
|
|
|
|
|
|
int changed;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_buffer_release {
|
|
|
|
/* The associated zwp_linux_buffer_release_v1 resource. */
|
|
|
|
struct wl_resource *resource;
|
|
|
|
/* How many weston_buffer_release_reference objects point to this
|
|
|
|
* object. */
|
|
|
|
uint32_t ref_count;
|
|
|
|
/* The fence fd, if any, associated with this release. If the fence fd
|
|
|
|
* is -1 then this is considered an immediate release. */
|
|
|
|
int fence_fd;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_buffer_release_reference {
|
|
|
|
struct weston_buffer_release *buffer_release;
|
|
|
|
/* Listener for the destruction of the wl_resource associated with the
|
|
|
|
* referenced buffer_release object. */
|
|
|
|
struct wl_listener destroy_listener;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_region {
|
|
|
|
struct wl_resource *resource;
|
|
|
|
pixman_region32_t region;
|
|
|
|
};
|
|
|
|
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
/* Using weston_view transformations
|
|
|
|
*
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
* To add a transformation to a view, create a struct weston_transform, and
|
|
|
|
* add it to the list view->geometry.transformation_list. Whenever you
|
|
|
|
* change the list, anything under view->geometry, or anything in the
|
|
|
|
* weston_transforms linked into the list, you must call
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
* weston_view_geometry_dirty().
|
|
|
|
*
|
|
|
|
* The order in the list defines the order of transformations. Let the list
|
|
|
|
* contain the transformation matrices M1, ..., Mn as head to tail. The
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
* transformation is applied to view-local coordinate vector p as
|
|
|
|
* P = Mn * ... * M2 * M1 * p
|
|
|
|
* to produce the global coordinate vector P. The total transform
|
|
|
|
* Mn * ... * M2 * M1
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
* is cached in view->transform.matrix, and the inverse of it in
|
|
|
|
* view->transform.inverse.
|
|
|
|
*
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
* The list always contains view->transform.position transformation, which
|
|
|
|
* is the translation by view->geometry.x and y.
|
|
|
|
*
|
|
|
|
* If you want to apply a transformation in local coordinates, add your
|
|
|
|
* weston_transform to the head of the list. If you want to apply a
|
|
|
|
* transformation in global coordinates, add it to the tail of the list.
|
|
|
|
*
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
* If view->geometry.parent is set, the total transformation of this
|
|
|
|
* view will be the parent's total transformation and this transformation
|
|
|
|
* combined:
|
|
|
|
* Mparent * Mn * ... * M2 * M1
|
|
|
|
*/
|
|
|
|
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
struct weston_view {
|
|
|
|
struct weston_surface *surface;
|
|
|
|
struct wl_list surface_link;
|
|
|
|
struct wl_signal destroy_signal;
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
|
|
|
|
/* struct weston_paint_node::view_link */
|
|
|
|
struct wl_list paint_node_list;
|
|
|
|
|
|
|
|
struct wl_list link; /* weston_compositor::view_list */
|
|
|
|
struct weston_layer_entry layer_link; /* part of geometry */
|
|
|
|
struct weston_plane *plane;
|
|
|
|
|
|
|
|
/* For weston_layer inheritance from another view */
|
|
|
|
struct weston_view *parent_view;
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
|
|
|
|
unsigned int click_to_activate_serial;
|
|
|
|
|
|
|
|
pixman_region32_t clip; /* See weston_view_damage_below() */
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
float alpha; /* part of geometry, see below */
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
|
|
|
/* Surface geometry state, mutable.
|
|
|
|
* If you change anything, call weston_surface_geometry_dirty().
|
|
|
|
* That includes the transformations referenced from the list.
|
|
|
|
*/
|
|
|
|
struct {
|
|
|
|
float x, y; /* surface translation on display */
|
|
|
|
|
|
|
|
/* struct weston_transform */
|
|
|
|
struct wl_list transformation_list;
|
|
|
|
|
|
|
|
/* managed by weston_view_set_transform_parent() */
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
struct weston_view *parent;
|
|
|
|
struct wl_listener parent_destroy_listener;
|
|
|
|
struct wl_list child_list; /* geometry.parent_link */
|
|
|
|
struct wl_list parent_link;
|
|
|
|
|
|
|
|
/* managed by weston_view_set_mask() */
|
|
|
|
bool scissor_enabled;
|
|
|
|
pixman_region32_t scissor; /* always a simple rect */
|
|
|
|
} geometry;
|
|
|
|
|
|
|
|
/* State derived from geometry state, read-only.
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
* This is updated by weston_view_update_transform().
|
|
|
|
*/
|
|
|
|
struct {
|
|
|
|
int dirty;
|
|
|
|
|
|
|
|
/* Approximations in global coordinates:
|
|
|
|
* - boundingbox is guaranteed to include the whole view in
|
|
|
|
* the smallest possible single rectangle.
|
|
|
|
* - opaque is guaranteed to be fully opaque, though not
|
|
|
|
* necessarily include all opaque areas.
|
|
|
|
*/
|
|
|
|
pixman_region32_t boundingbox;
|
|
|
|
pixman_region32_t opaque;
|
|
|
|
|
|
|
|
/* matrix and inverse are used only if enabled = 1.
|
|
|
|
* If enabled = 0, use x, y, width, height directly.
|
|
|
|
*/
|
|
|
|
int enabled;
|
|
|
|
struct weston_matrix matrix;
|
|
|
|
struct weston_matrix inverse;
|
|
|
|
|
|
|
|
struct weston_transform position; /* matrix from x, y */
|
|
|
|
} transform;
|
|
|
|
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
/*
|
|
|
|
* The primary output for this view.
|
|
|
|
* Used for picking the output for driving internal animations on the
|
|
|
|
* view, inheriting the primary output for related views in shells, etc.
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
*/
|
|
|
|
struct weston_output *output;
|
|
|
|
struct wl_listener output_destroy_listener;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
|
|
|
/*
|
|
|
|
* A more complete representation of all outputs this surface is
|
|
|
|
* displayed on.
|
|
|
|
*/
|
|
|
|
uint32_t output_mask;
|
|
|
|
|
|
|
|
/* Per-surface Presentation feedback flags, controlled by backend. */
|
|
|
|
uint32_t psf_flags;
|
|
|
|
|
|
|
|
bool is_mapped;
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_surface_state {
|
|
|
|
/* wl_surface.attach */
|
|
|
|
int newly_attached;
|
|
|
|
struct weston_buffer *buffer;
|
|
|
|
struct wl_listener buffer_destroy_listener;
|
|
|
|
int32_t sx;
|
|
|
|
int32_t sy;
|
|
|
|
|
|
|
|
/* wl_surface.damage */
|
|
|
|
pixman_region32_t damage_surface;
|
|
|
|
/* wl_surface.damage_buffer */
|
|
|
|
pixman_region32_t damage_buffer;
|
|
|
|
|
|
|
|
/* wl_surface.set_opaque_region */
|
|
|
|
pixman_region32_t opaque;
|
|
|
|
|
|
|
|
/* wl_surface.set_input_region */
|
|
|
|
pixman_region32_t input;
|
|
|
|
|
|
|
|
/* wl_surface.frame */
|
|
|
|
struct wl_list frame_callback_list;
|
|
|
|
|
|
|
|
/* presentation.feedback */
|
|
|
|
struct wl_list feedback_list;
|
|
|
|
|
|
|
|
/* wl_surface.set_buffer_transform */
|
|
|
|
/* wl_surface.set_scaling_factor */
|
|
|
|
/* wp_viewport.set_source */
|
|
|
|
/* wp_viewport.set_destination */
|
|
|
|
struct weston_buffer_viewport buffer_viewport;
|
libweston: Support zwp_surface_synchronization_v1.set_acquire_fence
Implement the set_acquire_fence request of the
zwp_surface_synchronization_v1 interface.
The implementation uses the acquire fence in two ways:
1. If the associated buffer is used as GL render source, an
EGLSyncKHR is created from the fence and used to synchronize
access.
2. If the associated buffer is used as a plane framebuffer,
the acquire fence is treated as an in-fence for the atomic
commit operation. If in-fences are not supported and the buffer
has an acquire fence, we don't consider it for plane placement.
If the used compositor/renderer doesn't support explicit
synchronization, we don't advertise the protocol at all. Currently only
the DRM and X11 backends when using the GL renderer advertise the
protocol for production use.
Issues for discussion
---------------------
a. Currently, a server-side wait of EGLSyncKHR is performed before
using the EGLImage/texture during rendering. Unfortunately, it's not clear
from the specs whether this is generally safe to do, or we need to
sync before glEGLImageTargetTexture2DOES. The exception is
TEXTURE_EXTERNAL_OES where the spec mentions it's enough to sync
and then glBindTexture for any changes to take effect.
Changes in v5:
- Meson support.
- Make explicit sync server error reporting more generic, supporting
all explicit sync related interfaces not just
wp_linux_surface_synchronization.
- Fix typo in warning for missing EGL_KHR_wait_sync extension.
- Support minor version 2 of the explicit sync protocol (i.e., support
fences for opaque EGL buffers).
Changes in v4:
- Introduce and use fd_clear and and fd_move helpers.
- Don't check for a valid buffer when updating surface acquire fence fd
from state.
- Assert that pending state acquire fence fd is always clear
after a commit.
- Clarify that WESTON_CAP_EXPLICIT_SYNC applies to just the
renderer.
- Check for EGL_KHR_wait_sync before using eglWaitSyncKHR.
- Dup the acquire fence before passing to EGL.
Changes in v3:
- Keep acquire_fence_fd in surface instead of buffer.
- Clarify that WESTON_CAP_EXPLICIT_SYNC applies to both backend and
renderer.
- Move comment about non-ownership of in_fence_fd to struct
drm_plane_state definition.
- Assert that we don't try to use planes with in-fences when using the
legacy KMS API.
- Remove unnecessary info from wayland error messages.
- Handle acquire fence for subsurface commits.
- Guard against self-update in fd_update.
- Disconnect the client if acquire fence EGLSyncKHR creation or wait
fails.
- Use updated protocol interface names.
- User correct format specifier for resource ids.
- Advertise protocol for X11 backend with GL renderer.
Changes in v2:
- Remove sync file wait fallbacks.
- Raise UNSUPPORTED_BUFFER error at commit if we have an acquire
fence, but the committed buffer is not a valid linux_dmabuf.
- Don't put buffers with in-fences on planes that don't support
in-fences.
- Don't advertise explicit sync protocol if backend does not
support explicit sync.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
6 years ago
|
|
|
|
|
|
|
/* zwp_surface_synchronization_v1.set_acquire_fence */
|
|
|
|
int acquire_fence_fd;
|
|
|
|
|
|
|
|
/* zwp_surface_synchronization_v1.get_release */
|
|
|
|
struct weston_buffer_release_reference buffer_release_ref;
|
libweston: Add support to set content-protection for a weston_surface
The protection requested for a given surface, must reach through the
weston_surface::pending_state, in the commit-cycle for the
weston_surface, so that it gets updated in the next commit.
As some protection is requested for a given weston_surface, it means
protection must be set for each of the outputs which show the surface.
While setting the protection of a weston_output, care must be taken
so as to avoid, degrading the protection of another surfaces, enjoying
the protection. For this purpose, all the weston_surfaces that are
shown on a weston_output are checked for their desired protection.
The highest of all such desired protections must be set for the
weston_output to avoid degrading of existing protected surfaces.
A surface requesting protection for a lower content-type can still be
provided protection for a higher type but the converse cannot be
allowed.
This patch adds support to set content-protection for a suface, which
inturn sets the content-protection for each of the outputs on which
it is shown, provided, none of the existing surface's protection
request is downgraded.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
6 years ago
|
|
|
|
|
|
|
/* weston_protected_surface.set_type */
|
|
|
|
enum weston_hdcp_protection desired_protection;
|
|
|
|
|
|
|
|
/* weston_protected_surface.enforced/relaxed */
|
|
|
|
enum weston_surface_protection_mode protection_mode;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_surface_activation_data {
|
|
|
|
struct weston_surface *surface;
|
|
|
|
struct weston_seat *seat;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_pointer_constraint {
|
|
|
|
struct wl_list link;
|
|
|
|
|
|
|
|
struct weston_surface *surface;
|
|
|
|
struct weston_view *view;
|
|
|
|
struct wl_resource *resource;
|
|
|
|
struct weston_pointer_grab grab;
|
|
|
|
struct weston_pointer *pointer;
|
|
|
|
uint32_t lifetime;
|
|
|
|
|
|
|
|
pixman_region32_t region;
|
|
|
|
pixman_region32_t region_pending;
|
|
|
|
bool region_is_pending;
|
|
|
|
|
|
|
|
wl_fixed_t hint_x;
|
|
|
|
wl_fixed_t hint_y;
|
|
|
|
wl_fixed_t hint_x_pending;
|
|
|
|
wl_fixed_t hint_y_pending;
|
|
|
|
bool hint_is_pending;
|
|
|
|
|
|
|
|
struct wl_listener pointer_destroy_listener;
|
|
|
|
struct wl_listener surface_destroy_listener;
|
|
|
|
struct wl_listener surface_commit_listener;
|
|
|
|
struct wl_listener surface_activate_listener;
|
|
|
|
};
|
|
|
|
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
struct weston_surface {
|
|
|
|
struct wl_resource *resource;
|
|
|
|
struct wl_signal destroy_signal; /* callback argument: this surface */
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
struct weston_compositor *compositor;
|
|
|
|
struct wl_signal commit_signal;
|
|
|
|
|
|
|
|
/* struct weston_paint_node::surface_link */
|
|
|
|
struct wl_list paint_node_list;
|
|
|
|
|
|
|
|
/** Damage in local coordinates from the client, for tex upload. */
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
pixman_region32_t damage;
|
|
|
|
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
pixman_region32_t opaque; /* part of geometry, see below */
|
|
|
|
pixman_region32_t input;
|
|
|
|
int32_t width, height;
|
|
|
|
int32_t ref_count;
|
|
|
|
|
|
|
|
/* Not for long-term storage. This exists for book-keeping while
|
|
|
|
* iterating over surfaces and views
|
|
|
|
*/
|
|
|
|
bool touched;
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
|
|
|
|
void *renderer_state;
|
|
|
|
|
|
|
|
struct wl_list views;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Which output to vsync this surface to.
|
|
|
|
* Used to determine whether to send or queue frame events, and for
|
|
|
|
* other client-visible syncing/throttling tied to the output
|
|
|
|
* repaint cycle.
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
*/
|
|
|
|
struct weston_output *output;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A more complete representation of all outputs this surface is
|
|
|
|
* displayed on.
|
|
|
|
*/
|
|
|
|
uint32_t output_mask;
|
|
|
|
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
struct wl_list frame_callback_list;
|
|
|
|
struct wl_list feedback_list;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
compositor: introduce weston_buffer_reference
The wl_buffer reference counting API has been inconsistent. You would
manually increment the refcount and register a destroy listener, as
opposed to calling weston_buffer_post_release(), which internally
decremented the refcount, and then removing a list item.
Replace both cases with a single function:
weston_buffer_reference(weston_buffer_reference *ref, wl_buffer *buffer)
Buffer is assigned to ref->buffer, while taking care of all the refcounting
and release posting. You take a reference by passing a non-NULL buffer, and
release a reference by passing NULL as buffer. The function uses an
internal wl_buffer destroy listener, so the pointer gets reset on
destruction automatically.
This is inspired by the pipe_resource_reference() of Mesa, and modified
by krh's suggestion to add struct weston_buffer_reference.
Additionally, when a surface gets destroyed, the associated wl_buffer
will send a release event. Often the buffer is already destroyed on
client side, so the event will be discarded by libwayland-client.
Compositor-drm.c is converted to use weston_buffer_reference.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
12 years ago
|
|
|
struct weston_buffer_reference buffer_ref;
|
|
|
|
struct weston_buffer_viewport buffer_viewport;
|
|
|
|
int32_t width_from_buffer; /* before applying viewport */
|
|
|
|
int32_t height_from_buffer;
|
|
|
|
bool keep_buffer; /* for backends to prevent early release */
|
|
|
|
|
|
|
|
/* wp_viewport resource for this surface */
|
|
|
|
struct wl_resource *viewport_resource;
|
|
|
|
|
|
|
|
/* All the pending state, that wl_surface.commit will apply. */
|
|
|
|
struct weston_surface_state pending;
|
|
|
|
|
|
|
|
/* Matrices representing of the full transformation between
|
|
|
|
* buffer and surface coordinates. These matrices are updated
|
|
|
|
* using the weston_surface_build_buffer_matrix function. */
|
|
|
|
struct weston_matrix buffer_to_surface_matrix;
|
|
|
|
struct weston_matrix surface_to_buffer_matrix;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If non-NULL, this function will be called on
|
|
|
|
* wl_surface::commit after a new buffer has been set up for
|
|
|
|
* this surface. The integer params are the sx and sy
|
|
|
|
* parameters supplied to wl_surface::attach.
|
|
|
|
*/
|
|
|
|
void (*committed)(struct weston_surface *es, int32_t sx, int32_t sy);
|
|
|
|
void *committed_private;
|
compositor: add weston_surface_set_label_func()
When printing out logs from Weston's actions, mainly for debugging, it
can be very difficult to identify the different surfaces. Inspecting
the configure function pointer is not useful, as the configure functions
may live in modules.
Add vfunc get_label to weston_surface, which will produce a short,
human-readable description of the surface, which allows identifying it
better, rather than just looking at the surface size, for instance.
Set the label function from most parts of Weston, to identify cursors and
drag icons, and panels, backgrounds, screensavers and lock surfaces, and
the desktop shell's application surfaces.
v2: renamed 'description' to 'label', so we get
weston_surface_set_label_func().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
10 years ago
|
|
|
int (*get_label)(struct weston_surface *surface, char *buf, size_t len);
|
compositor: introduce sub-surfaces
Implement the basic protocol for sub-surfaces:
- expose wl_subcompositor global interface
- error checking on protocol calls
- associate a parent wl_surface to a sub-surface
- introduce the sub-surface role, which is exclusive
- an implementation of the wl_subsurface interface
- allow nesting of sub-surfaces
- proper surface transformation inheritance from parent to sub-surfaces
- two different modes of wl_surface.commit for sub-surfaces
- hook sub-surfaces up to repaint by modifying the repaint list code
Struct weston_subsurface is dynamically allocated. For sub-surfaces, it
is completely populated.
For parent surfaces, weston_subsurface acts only as a link for stacking
order purposes. The wl_resource is unused, parent_destroy_listener is
not registered, the transform is not linked, etc.
Sub-surfaces are not added directly into layers for display or input.
Instead, they are hooked up via the sub-surface list present in parent
weston_surface. This way sub-surfaces are inherently linked to the
parent surface, and cannot be displayed unless the parent is mapped,
too. This also eases restacking, as only the parent will be in a layer
list. Also, only the main surface should be subject to shell actions.
The surface list rebuilding in weston_output_repaint() is modified to
process sub-surface lists, if they are non-empty. The sub-surface list
always contains the parent, too, unless empty. The collection of
frame_callback_list is moved to a later loop, to streamline the surface
list rebuild functions.
Features still lacking are:
- full-surface alpha support for compound windows
Changes in v2:
- fix a bug in surface mapping: commit a sub-surface would cause the
main surface to never be mapped.
- remove debug printfs
- detect attempt of making a surface its own parent
- always zero-alloc weston_subsurface
- apply wl_subsurface.set_position in commit, not immediately
- add weston_surface_to_subsurface()
- implement sub-surface commit modes parent-cached and independent
- implement wl_subcompositor.destroy and wl_subsurface.destroy
Changes in v3:
- rebased, and use the new transform inheritance code
- squashed the commit "add sub-surfaces to repaint list"
- fixed a buffer reference leak in commit_from_cache()
- Rewrite the sub-surface destructor code, and make it leave the
wl_subsurface protocol object inert, if one destroys the corresponding
wl_surface.
- replaced set_commit_mode with set_sync and set_desync
- allowed sub-surface nesting, and fixed repaint accordingly
- implemented nested sub-surface commit modes
- Made the sub-surface order changes from wl_subsurface.place_above and
.place_below to be applied when the parent surface state is applied,
instead of immediately. This conforms with the protocol specification
now.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
12 years ago
|
|
|
|
|
|
|
/* Parent's list of its sub-surfaces, weston_subsurface:parent_link.
|
|
|
|
* Contains also the parent itself as a dummy weston_subsurface,
|
|
|
|
* if the list is not empty.
|
|
|
|
*/
|
|
|
|
struct wl_list subsurface_list; /* weston_subsurface::parent_link */
|
|
|
|
struct wl_list subsurface_list_pending; /* ...::parent_link_pending */
|
compositor: send error for surface role resets
With the more accurate definition of wl_surface roles in Wayland,
enforce the restriction: a role is always set permanently, and
attempting to change it is a protocol error.
This patch is based on Jasper's patch:
http://lists.freedesktop.org/archives/wayland-devel/2014-August/016811.html
The difference in this patch compared to his are:
- send role errors on the interface whose request triggers it, not on
wl_surface
- an interface could have several requests assigning different roles,
cannot use wl_interface as the unique key; use an arbitary string
instead
- ensure in window-manager.c that create_shell_surface() ->
create_common_surface() is never called with surface->configure set,
to avoid compositor abort
- use wl_resource_post_no_memory() where appropriate instead of
hand-rolling it with wl_resource_post_error()
Ideally we would not add weston_surface::role_name field, but use
weston_surface::configure. At the moment this is not possible though,
because at least shell.c uses several different roles with the same
configure function. Drag'n'drop uses two configure functions for the
same role. The configure hook is also reset in several places,
which is not good for role tracking.
This patch overlooks the wl_surface roles assigned in privileged
extensions: screensaver, panel, background, lock, input panel.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
10 years ago
|
|
|
|
|
|
|
/*
|
|
|
|
* For tracking protocol role assignments. Different roles may
|
|
|
|
* have the same configure hook, e.g. in shell.c. Configure hook
|
|
|
|
* may get reset, this will not.
|
|
|
|
* XXX: map configure functions 1:1 to roles, and never reset it,
|
|
|
|
* and replace role_name with configure.
|
|
|
|
*/
|
|
|
|
const char *role_name;
|
compositor: Implement JSON-timeline logging
Logging is activated and deactivated with the debug key binding 't'.
When activated, it creates a new log file, where it records the events.
The log file contains events and detailed object information entries in
JSON format, and is meant to be parsed in sequence from beginning to the
end.
The emitted events are mostly related to the output repaint cycle, like
when repaint begins, is submitted to GPU, and when it completes on a
vblank. This is recorded per-output. Also some per-surface events are
recorded, including when surface damage is flushed.
To reduce the log size, events refer to objects like outputs and
surfaces by id numbers. Detailed object information is emitted only as
needed: on the first object occurrence, and afterwards only if
weston_timeline_object::force_refresh asks for it.
The detailed information for surfaces includes the string returned by
weston_surface::get_label. Therefore it is important to set
weston_timeline_object::force_refresh = 1 whenever the string would
change, so that the new details get recorded.
A rudimentary parser and SVG generator can be found at:
https://github.com/ppaalanen/wesgr
The timeline logs can answer questions including:
- How does the compositor repaint cycle work timing-wise?
- When was the vblank deadline missed?
- What is the latency from surface commit to showing the new content on
screen?
- How long does it take to process the scenegraph?
v2: weston_surface::get_description renamed to get_label.
v3: reafctor a bit into fprint_quoted_string().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
10 years ago
|
|
|
|
|
|
|
bool is_mapped;
|
|
|
|
bool is_opaque;
|
|
|
|
|
|
|
|
/* An list of per seat pointer constraints. */
|
|
|
|
struct wl_list pointer_constraints;
|
|
|
|
|
|
|
|
/* zwp_surface_synchronization_v1 resource for this surface */
|
|
|
|
struct wl_resource *synchronization_resource;
|
libweston: Support zwp_surface_synchronization_v1.set_acquire_fence
Implement the set_acquire_fence request of the
zwp_surface_synchronization_v1 interface.
The implementation uses the acquire fence in two ways:
1. If the associated buffer is used as GL render source, an
EGLSyncKHR is created from the fence and used to synchronize
access.
2. If the associated buffer is used as a plane framebuffer,
the acquire fence is treated as an in-fence for the atomic
commit operation. If in-fences are not supported and the buffer
has an acquire fence, we don't consider it for plane placement.
If the used compositor/renderer doesn't support explicit
synchronization, we don't advertise the protocol at all. Currently only
the DRM and X11 backends when using the GL renderer advertise the
protocol for production use.
Issues for discussion
---------------------
a. Currently, a server-side wait of EGLSyncKHR is performed before
using the EGLImage/texture during rendering. Unfortunately, it's not clear
from the specs whether this is generally safe to do, or we need to
sync before glEGLImageTargetTexture2DOES. The exception is
TEXTURE_EXTERNAL_OES where the spec mentions it's enough to sync
and then glBindTexture for any changes to take effect.
Changes in v5:
- Meson support.
- Make explicit sync server error reporting more generic, supporting
all explicit sync related interfaces not just
wp_linux_surface_synchronization.
- Fix typo in warning for missing EGL_KHR_wait_sync extension.
- Support minor version 2 of the explicit sync protocol (i.e., support
fences for opaque EGL buffers).
Changes in v4:
- Introduce and use fd_clear and and fd_move helpers.
- Don't check for a valid buffer when updating surface acquire fence fd
from state.
- Assert that pending state acquire fence fd is always clear
after a commit.
- Clarify that WESTON_CAP_EXPLICIT_SYNC applies to just the
renderer.
- Check for EGL_KHR_wait_sync before using eglWaitSyncKHR.
- Dup the acquire fence before passing to EGL.
Changes in v3:
- Keep acquire_fence_fd in surface instead of buffer.
- Clarify that WESTON_CAP_EXPLICIT_SYNC applies to both backend and
renderer.
- Move comment about non-ownership of in_fence_fd to struct
drm_plane_state definition.
- Assert that we don't try to use planes with in-fences when using the
legacy KMS API.
- Remove unnecessary info from wayland error messages.
- Handle acquire fence for subsurface commits.
- Guard against self-update in fd_update.
- Disconnect the client if acquire fence EGLSyncKHR creation or wait
fails.
- Use updated protocol interface names.
- User correct format specifier for resource ids.
- Advertise protocol for X11 backend with GL renderer.
Changes in v2:
- Remove sync file wait fallbacks.
- Raise UNSUPPORTED_BUFFER error at commit if we have an acquire
fence, but the committed buffer is not a valid linux_dmabuf.
- Don't put buffers with in-fences on planes that don't support
in-fences.
- Don't advertise explicit sync protocol if backend does not
support explicit sync.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
6 years ago
|
|
|
int acquire_fence_fd;
|
|
|
|
struct weston_buffer_release_reference buffer_release_ref;
|
libweston: Add support to set content-protection for a weston_surface
The protection requested for a given surface, must reach through the
weston_surface::pending_state, in the commit-cycle for the
weston_surface, so that it gets updated in the next commit.
As some protection is requested for a given weston_surface, it means
protection must be set for each of the outputs which show the surface.
While setting the protection of a weston_output, care must be taken
so as to avoid, degrading the protection of another surfaces, enjoying
the protection. For this purpose, all the weston_surfaces that are
shown on a weston_output are checked for their desired protection.
The highest of all such desired protections must be set for the
weston_output to avoid degrading of existing protected surfaces.
A surface requesting protection for a lower content-type can still be
provided protection for a higher type but the converse cannot be
allowed.
This patch adds support to set content-protection for a suface, which
inturn sets the content-protection for each of the outputs on which
it is shown, provided, none of the existing surface's protection
request is downgraded.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
6 years ago
|
|
|
|
|
|
|
struct weston_dmabuf_feedback *dmabuf_feedback;
|
|
|
|
|
libweston: Add support to set content-protection for a weston_surface
The protection requested for a given surface, must reach through the
weston_surface::pending_state, in the commit-cycle for the
weston_surface, so that it gets updated in the next commit.
As some protection is requested for a given weston_surface, it means
protection must be set for each of the outputs which show the surface.
While setting the protection of a weston_output, care must be taken
so as to avoid, degrading the protection of another surfaces, enjoying
the protection. For this purpose, all the weston_surfaces that are
shown on a weston_output are checked for their desired protection.
The highest of all such desired protections must be set for the
weston_output to avoid degrading of existing protected surfaces.
A surface requesting protection for a lower content-type can still be
provided protection for a higher type but the converse cannot be
allowed.
This patch adds support to set content-protection for a suface, which
inturn sets the content-protection for each of the outputs on which
it is shown, provided, none of the existing surface's protection
request is downgraded.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
6 years ago
|
|
|
enum weston_hdcp_protection desired_protection;
|
|
|
|
enum weston_hdcp_protection current_protection;
|
|
|
|
enum weston_surface_protection_mode protection_mode;
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
};
|
|
|
|
|
|
|
|
struct weston_subsurface {
|
|
|
|
struct wl_resource *resource;
|
|
|
|
|
|
|
|
/* guaranteed to be valid and non-NULL */
|
|
|
|
struct weston_surface *surface;
|
|
|
|
struct wl_listener surface_destroy_listener;
|
|
|
|
|
|
|
|
/* can be NULL */
|
|
|
|
struct weston_surface *parent;
|
|
|
|
struct wl_listener parent_destroy_listener;
|
|
|
|
struct wl_list parent_link;
|
|
|
|
struct wl_list parent_link_pending;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
int32_t x;
|
|
|
|
int32_t y;
|
|
|
|
int set;
|
|
|
|
} position;
|
|
|
|
|
|
|
|
int has_cached_data;
|
|
|
|
struct weston_surface_state cached;
|
|
|
|
struct weston_buffer_reference cached_buffer_ref;
|
|
|
|
|
|
|
|
/* Sub-surface has been reordered; need to apply damage. */
|
|
|
|
bool reordered;
|
|
|
|
|
|
|
|
int synchronized;
|
|
|
|
|
|
|
|
/* Used for constructing the view tree */
|
|
|
|
struct wl_list unused_views;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct protected_surface {
|
|
|
|
struct weston_surface *surface;
|
|
|
|
struct wl_listener surface_destroy_listener;
|
|
|
|
struct wl_list link;
|
|
|
|
struct wl_resource *protection_resource;
|
|
|
|
struct content_protection *cp_backptr;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct content_protection {
|
|
|
|
struct weston_compositor *compositor;
|
|
|
|
struct wl_listener destroy_listener;
|
|
|
|
struct weston_log_scope *debug;
|
|
|
|
struct wl_list protected_list;
|
|
|
|
struct wl_event_source *surface_protection_update;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
enum weston_key_state_update {
|
|
|
|
STATE_UPDATE_AUTOMATIC,
|
|
|
|
STATE_UPDATE_NONE,
|
|
|
|
};
|
|
|
|
|
|
|
|
enum weston_activate_flag {
|
|
|
|
WESTON_ACTIVATE_FLAG_NONE = 0,
|
|
|
|
WESTON_ACTIVATE_FLAG_CONFIGURE = 1 << 0,
|
|
|
|
WESTON_ACTIVATE_FLAG_CLICKED = 1 << 1,
|
|
|
|
};
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_version(int *major, int *minor, int *micro);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_view_set_output(struct weston_view *view, struct weston_output *output);
|
|
|
|
|
|
|
|
void
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
weston_view_update_transform(struct weston_view *view);
|
|
|
|
|
|
|
|
void
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
weston_view_geometry_dirty(struct weston_view *view);
|
|
|
|
|
|
|
|
void
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
weston_view_to_global_float(struct weston_view *view,
|
|
|
|
float sx, float sy, float *x, float *y);
|
|
|
|
|
|
|
|
void
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
weston_view_from_global(struct weston_view *view,
|
|
|
|
int32_t x, int32_t y, int32_t *vx, int32_t *vy);
|
|
|
|
void
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
weston_view_from_global_fixed(struct weston_view *view,
|
|
|
|
wl_fixed_t x, wl_fixed_t y,
|
|
|
|
wl_fixed_t *vx, wl_fixed_t *vy);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_view_activate_input(struct weston_view *view,
|
|
|
|
struct weston_seat *seat,
|
|
|
|
uint32_t flags);
|
|
|
|
|
|
|
|
void
|
|
|
|
notify_modifiers(struct weston_seat *seat, uint32_t serial);
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
|
|
|
void
|
|
|
|
weston_layer_entry_insert(struct weston_layer_entry *list,
|
|
|
|
struct weston_layer_entry *entry);
|
|
|
|
void
|
|
|
|
weston_layer_entry_remove(struct weston_layer_entry *entry);
|
|
|
|
void
|
|
|
|
weston_layer_init(struct weston_layer *layer,
|
|
|
|
struct weston_compositor *compositor);
|
|
|
|
void
|
|
|
|
weston_layer_fini(struct weston_layer *layer);
|
|
|
|
void
|
|
|
|
weston_layer_set_position(struct weston_layer *layer,
|
|
|
|
enum weston_layer_position position);
|
|
|
|
void
|
|
|
|
weston_layer_unset_position(struct weston_layer *layer);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_layer_set_mask(struct weston_layer *layer, int x, int y, int width, int height);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_layer_set_mask_infinite(struct weston_layer *layer);
|
|
|
|
|
|
|
|
bool
|
|
|
|
weston_layer_mask_is_infinite(struct weston_layer *layer);
|
|
|
|
|
compositor: set presentation.presented flags
Change weston_output_finish_frame() signature so that backends are
required to set the flags, that will be reported on the Presentation
'presented' event. This is meant for output-wide feedback flags. Flags
that vary per wl_surface are subject for the following patch.
All start_repaint_loop functions use the special private flag
PRESENTATION_FEEDBACK_INVALID to mark, that this call of
weston_output_finish_frame() cannot trigger the 'presented' event. If it
does, we now hit an assert, and should then investigate why a fake update
triggered Presentation feedback.
DRM:
Page flip is always vsync'd, and always gets the completion timestamp
from the kernel which should correspond well to hardware. Completion is
triggered by the kernel/hardware.
Vblank handler is only used with the broken planes path, therefore do
not report VSYNC, because we cannot guarantee all the planes updated at
the same time. We cannot set the INVALID, because it would abort the
compositor if the broken planes path was ever used. This is a hack that
will get fixed with nuclear pageflip support in the future.
fbdev:
No vsync, update done by copy, no completion event from hardware, and
completion time is totally fake.
headless:
No real output to update.
RDP:
Guessing that maybe no vsync, fake time, and copy make sense (pixels
sent over network). Also no event that the pixels have been shown?
RPI:
Presumably Dispmanx updates are vsync'd. We get a completion event from
the driver, but need to read the clock ourselves, so the completion time
is somewhat unreliable. Zero-copy flag not implemented though it would
be theoretically possible with EGL clients (zero-copy is a per-surface
flag anyway, so in this patch).
Wayland:
No information how the host compositor is doing updates, so make a safe
guess without assuming vsync or hardware completion event. While we do
get some timestamp from the host compositor, it is not the completion
time. Would need to hook to the Presentation extension of the host
compositor to get more accurate flags.
X11:
No idea about vsync, completion event, or copying. Also the timestamp is
a fake.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Acked-by: Mario Kleiner <mario.kleiner.de@gmail.com>
10 years ago
|
|
|
/* An invalid flag in presented_flags to catch logic errors. */
|
|
|
|
#define WP_PRESENTATION_FEEDBACK_INVALID (1U << 31)
|
compositor: set presentation.presented flags
Change weston_output_finish_frame() signature so that backends are
required to set the flags, that will be reported on the Presentation
'presented' event. This is meant for output-wide feedback flags. Flags
that vary per wl_surface are subject for the following patch.
All start_repaint_loop functions use the special private flag
PRESENTATION_FEEDBACK_INVALID to mark, that this call of
weston_output_finish_frame() cannot trigger the 'presented' event. If it
does, we now hit an assert, and should then investigate why a fake update
triggered Presentation feedback.
DRM:
Page flip is always vsync'd, and always gets the completion timestamp
from the kernel which should correspond well to hardware. Completion is
triggered by the kernel/hardware.
Vblank handler is only used with the broken planes path, therefore do
not report VSYNC, because we cannot guarantee all the planes updated at
the same time. We cannot set the INVALID, because it would abort the
compositor if the broken planes path was ever used. This is a hack that
will get fixed with nuclear pageflip support in the future.
fbdev:
No vsync, update done by copy, no completion event from hardware, and
completion time is totally fake.
headless:
No real output to update.
RDP:
Guessing that maybe no vsync, fake time, and copy make sense (pixels
sent over network). Also no event that the pixels have been shown?
RPI:
Presumably Dispmanx updates are vsync'd. We get a completion event from
the driver, but need to read the clock ourselves, so the completion time
is somewhat unreliable. Zero-copy flag not implemented though it would
be theoretically possible with EGL clients (zero-copy is a per-surface
flag anyway, so in this patch).
Wayland:
No information how the host compositor is doing updates, so make a safe
guess without assuming vsync or hardware completion event. While we do
get some timestamp from the host compositor, it is not the completion
time. Would need to hook to the Presentation extension of the host
compositor to get more accurate flags.
X11:
No idea about vsync, completion event, or copying. Also the timestamp is
a fake.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Acked-by: Mario Kleiner <mario.kleiner.de@gmail.com>
10 years ago
|
|
|
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
void
|
|
|
|
weston_output_schedule_repaint(struct weston_output *output);
|
|
|
|
void
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
weston_compositor_schedule_repaint(struct weston_compositor *compositor);
|
|
|
|
void
|
|
|
|
weston_compositor_damage_all(struct weston_compositor *compositor);
|
|
|
|
void
|
|
|
|
weston_compositor_wake(struct weston_compositor *compositor);
|
|
|
|
void
|
|
|
|
weston_compositor_sleep(struct weston_compositor *compositor);
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
struct weston_view *
|
|
|
|
weston_compositor_pick_view(struct weston_compositor *compositor,
|
|
|
|
wl_fixed_t x, wl_fixed_t y,
|
|
|
|
wl_fixed_t *sx, wl_fixed_t *sy);
|
|
|
|
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
|
|
|
struct weston_binding;
|
|
|
|
typedef void (*weston_key_binding_handler_t)(struct weston_keyboard *keyboard,
|
|
|
|
const struct timespec *time,
|
|
|
|
uint32_t key,
|
|
|
|
void *data);
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
struct weston_binding *
|
|
|
|
weston_compositor_add_key_binding(struct weston_compositor *compositor,
|
|
|
|
uint32_t key,
|
|
|
|
enum weston_keyboard_modifier modifier,
|
|
|
|
weston_key_binding_handler_t binding,
|
|
|
|
void *data);
|
|
|
|
struct weston_binding *
|
|
|
|
weston_compositor_add_debug_binding(struct weston_compositor *compositor,
|
|
|
|
uint32_t key,
|
|
|
|
weston_key_binding_handler_t binding,
|
|
|
|
void *data);
|
|
|
|
|
|
|
|
typedef void (*weston_modifier_binding_handler_t)(struct weston_keyboard *keyboard,
|
|
|
|
enum weston_keyboard_modifier modifier,
|
|
|
|
void *data);
|
|
|
|
struct weston_binding *
|
|
|
|
weston_compositor_add_modifier_binding(struct weston_compositor *compositor,
|
|
|
|
enum weston_keyboard_modifier modifier,
|
|
|
|
weston_modifier_binding_handler_t binding,
|
|
|
|
void *data);
|
|
|
|
|
|
|
|
typedef void (*weston_button_binding_handler_t)(struct weston_pointer *pointer,
|
|
|
|
const struct timespec *time,
|
|
|
|
uint32_t button,
|
|
|
|
void *data);
|
|
|
|
struct weston_binding *
|
|
|
|
weston_compositor_add_button_binding(struct weston_compositor *compositor,
|
|
|
|
uint32_t button,
|
|
|
|
enum weston_keyboard_modifier modifier,
|
|
|
|
weston_button_binding_handler_t binding,
|
|
|
|
void *data);
|
|
|
|
|
|
|
|
typedef void (*weston_touch_binding_handler_t)(struct weston_touch *touch,
|
|
|
|
const struct timespec *time,
|
|
|
|
void *data);
|
|
|
|
struct weston_binding *
|
|
|
|
weston_compositor_add_touch_binding(struct weston_compositor *compositor,
|
|
|
|
enum weston_keyboard_modifier modifier,
|
|
|
|
weston_touch_binding_handler_t binding,
|
|
|
|
void *data);
|
|
|
|
|
|
|
|
typedef void (*weston_axis_binding_handler_t)(struct weston_pointer *pointer,
|
|
|
|
const struct timespec *time,
|
|
|
|
struct weston_pointer_axis_event *event,
|
|
|
|
void *data);
|
|
|
|
struct weston_binding *
|
|
|
|
weston_compositor_add_axis_binding(struct weston_compositor *compositor,
|
|
|
|
uint32_t axis,
|
|
|
|
enum weston_keyboard_modifier modifier,
|
|
|
|
weston_axis_binding_handler_t binding,
|
|
|
|
void *data);
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
|
|
|
void
|
|
|
|
weston_binding_destroy(struct weston_binding *binding);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_install_debug_key_binding(struct weston_compositor *compositor,
|
|
|
|
uint32_t mod);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_compositor_set_default_pointer_grab(struct weston_compositor *compositor,
|
|
|
|
const struct weston_pointer_grab_interface *interface);
|
|
|
|
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
struct weston_surface *
|
|
|
|
weston_surface_create(struct weston_compositor *compositor);
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
struct weston_view *
|
|
|
|
weston_view_create(struct weston_surface *surface);
|
|
|
|
|
|
|
|
struct weston_buffer_reference *
|
|
|
|
weston_buffer_create_solid_rgba(struct weston_compositor *compositor,
|
|
|
|
float r, float g, float b, float a);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_surface_attach_solid(struct weston_surface *surface,
|
|
|
|
struct weston_buffer_reference *buffer_ref,
|
|
|
|
int w, int h);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_buffer_destroy_solid(struct weston_buffer_reference *buffer_ref);
|
|
|
|
|
|
|
|
bool
|
|
|
|
weston_surface_has_content(struct weston_surface *surface);
|
|
|
|
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
void
|
|
|
|
weston_view_destroy(struct weston_view *view);
|
|
|
|
|
|
|
|
void
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
weston_view_set_position(struct weston_view *view,
|
|
|
|
float x, float y);
|
|
|
|
|
|
|
|
void
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
weston_view_set_transform_parent(struct weston_view *view,
|
|
|
|
struct weston_view *parent);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_view_set_mask(struct weston_view *view,
|
|
|
|
int x, int y, int width, int height);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_view_set_mask_infinite(struct weston_view *view);
|
|
|
|
|
|
|
|
bool
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
weston_view_is_mapped(struct weston_view *view);
|
|
|
|
|
|
|
|
void
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
weston_view_schedule_repaint(struct weston_view *view);
|
|
|
|
|
|
|
|
bool
|
|
|
|
weston_surface_is_mapped(struct weston_surface *surface);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_surface_set_size(struct weston_surface *surface,
|
|
|
|
int32_t width, int32_t height);
|
|
|
|
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
void
|
|
|
|
weston_surface_damage(struct weston_surface *surface);
|
|
|
|
|
|
|
|
void
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
weston_view_damage_below(struct weston_view *view);
|
|
|
|
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
void
|
|
|
|
weston_view_unmap(struct weston_view *view);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_surface_map(struct weston_surface *surface);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_surface_unmap(struct weston_surface *surface);
|
|
|
|
|
shell: keyboard focus and restacking fixes for sub-surfaces
The shell needs to redirect some actions to the parent surface, when
they originally target a sub-surface. This patch implements the
following:
- Move, resize, and rotate bindings always target the parent surface.
- Opacity (full-surface alpha) binding targets the parent surface. This
is broken, because it should change the opacity of the whole compound
window, which is difficult to implement in the renderer.
- click_to_activate_binding() needs to check the shell surface type from
the main surface, because sub-surface would produce SHELL_SURFACE_NONE
and prevent activation.
- Also activate() needs to check the type from the main surface, and
restack the main surface. Keyboard focus is assigned to the original
(sub-)surface.
- focus_state_surface_destroy() needs to handle sub-surfaces: only the
main surface will be in a layer list. If the destroyed surface is
indeed a sub-surface, activate the main surface next. This way a
client that destroys a focused sub-surface still retains focus in the
same window.
- The workspace_manager.move_surface request can accept also
sub-surfaces, and it will move the corresponding main surface.
Changes in v2:
- do not special-case keyboard focus for sub-surfaces
- fix surface type checks for sub-surfaces in shell, fix restacking of
sub-surfaces in shell, fix focus_state_surface_destroy()
Changes in v3:
- Renamed weston_surface_get_parent() to
weston_surface_get_main_surface() to be more explicit that this is
about sub-surfaces
- Fixed move_surface_to_workspace() to handle keyboard focus on a
sub-surface.
- Used a temporary variable in several places to clarify code, instead
of reassigning a variable.
- Fixed workspace_manager_move_surface() to deal with sub-surfaces.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
12 years ago
|
|
|
struct weston_surface *
|
|
|
|
weston_surface_get_main_surface(struct weston_surface *surface);
|
|
|
|
|
compositor: send error for surface role resets
With the more accurate definition of wl_surface roles in Wayland,
enforce the restriction: a role is always set permanently, and
attempting to change it is a protocol error.
This patch is based on Jasper's patch:
http://lists.freedesktop.org/archives/wayland-devel/2014-August/016811.html
The difference in this patch compared to his are:
- send role errors on the interface whose request triggers it, not on
wl_surface
- an interface could have several requests assigning different roles,
cannot use wl_interface as the unique key; use an arbitary string
instead
- ensure in window-manager.c that create_shell_surface() ->
create_common_surface() is never called with surface->configure set,
to avoid compositor abort
- use wl_resource_post_no_memory() where appropriate instead of
hand-rolling it with wl_resource_post_error()
Ideally we would not add weston_surface::role_name field, but use
weston_surface::configure. At the moment this is not possible though,
because at least shell.c uses several different roles with the same
configure function. Drag'n'drop uses two configure functions for the
same role. The configure hook is also reset in several places,
which is not good for role tracking.
This patch overlooks the wl_surface roles assigned in privileged
extensions: screensaver, panel, background, lock, input panel.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
10 years ago
|
|
|
int
|
|
|
|
weston_surface_set_role(struct weston_surface *surface,
|
|
|
|
const char *role_name,
|
|
|
|
struct wl_resource *error_resource,
|
|
|
|
uint32_t error_code);
|
|
|
|
const char *
|
|
|
|
weston_surface_get_role(struct weston_surface *surface);
|
compositor: send error for surface role resets
With the more accurate definition of wl_surface roles in Wayland,
enforce the restriction: a role is always set permanently, and
attempting to change it is a protocol error.
This patch is based on Jasper's patch:
http://lists.freedesktop.org/archives/wayland-devel/2014-August/016811.html
The difference in this patch compared to his are:
- send role errors on the interface whose request triggers it, not on
wl_surface
- an interface could have several requests assigning different roles,
cannot use wl_interface as the unique key; use an arbitary string
instead
- ensure in window-manager.c that create_shell_surface() ->
create_common_surface() is never called with surface->configure set,
to avoid compositor abort
- use wl_resource_post_no_memory() where appropriate instead of
hand-rolling it with wl_resource_post_error()
Ideally we would not add weston_surface::role_name field, but use
weston_surface::configure. At the moment this is not possible though,
because at least shell.c uses several different roles with the same
configure function. Drag'n'drop uses two configure functions for the
same role. The configure hook is also reset in several places,
which is not good for role tracking.
This patch overlooks the wl_surface roles assigned in privileged
extensions: screensaver, panel, background, lock, input panel.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
10 years ago
|
|
|
|
compositor: add weston_surface_set_label_func()
When printing out logs from Weston's actions, mainly for debugging, it
can be very difficult to identify the different surfaces. Inspecting
the configure function pointer is not useful, as the configure functions
may live in modules.
Add vfunc get_label to weston_surface, which will produce a short,
human-readable description of the surface, which allows identifying it
better, rather than just looking at the surface size, for instance.
Set the label function from most parts of Weston, to identify cursors and
drag icons, and panels, backgrounds, screensavers and lock surfaces, and
the desktop shell's application surfaces.
v2: renamed 'description' to 'label', so we get
weston_surface_set_label_func().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
10 years ago
|
|
|
void
|
|
|
|
weston_surface_set_label_func(struct weston_surface *surface,
|
|
|
|
int (*desc)(struct weston_surface *,
|
|
|
|
char *, size_t));
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_surface_get_content_size(struct weston_surface *surface,
|
|
|
|
int *width, int *height);
|
|
|
|
|
|
|
|
struct weston_geometry
|
|
|
|
weston_surface_get_bounding_box(struct weston_surface *surface);
|
|
|
|
|
|
|
|
int
|
|
|
|
weston_surface_copy_content(struct weston_surface *surface,
|
|
|
|
void *target, size_t size,
|
|
|
|
int src_x, int src_y,
|
|
|
|
int width, int height);
|
|
|
|
|
|
|
|
struct weston_buffer *
|
|
|
|
weston_buffer_from_resource(struct weston_compositor *ec,
|
|
|
|
struct wl_resource *resource);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_compositor_get_time(struct timespec *time);
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
|
|
|
void
|
|
|
|
weston_compositor_destroy(struct weston_compositor *ec);
|
|
|
|
|
|
|
|
struct weston_compositor *
|
|
|
|
weston_compositor_create(struct wl_display *display,
|
|
|
|
struct weston_log_context *log_ctx, void *user_data,
|
|
|
|
const struct weston_testsuite_data *test_data);
|
|
|
|
|
|
|
|
void *
|
|
|
|
weston_compositor_get_test_data(struct weston_compositor *ec);
|
|
|
|
|
|
|
|
bool
|
|
|
|
weston_compositor_add_destroy_listener_once(struct weston_compositor *compositor,
|
|
|
|
struct wl_listener *listener,
|
|
|
|
wl_notify_func_t destroy_handler);
|
|
|
|
|
|
|
|
enum weston_compositor_backend {
|
|
|
|
WESTON_BACKEND_DRM,
|
|
|
|
WESTON_BACKEND_HEADLESS,
|
|
|
|
WESTON_BACKEND_RDP,
|
|
|
|
WESTON_BACKEND_WAYLAND,
|
|
|
|
WESTON_BACKEND_X11,
|
|
|
|
};
|
|
|
|
|
|
|
|
int
|
|
|
|
weston_compositor_load_backend(struct weston_compositor *compositor,
|
|
|
|
enum weston_compositor_backend backend,
|
|
|
|
struct weston_backend_config *config_base);
|
|
|
|
void
|
|
|
|
weston_compositor_exit(struct weston_compositor *ec);
|
|
|
|
void *
|
|
|
|
weston_compositor_get_user_data(struct weston_compositor *compositor);
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
void
|
|
|
|
weston_compositor_exit_with_code(struct weston_compositor *compositor,
|
|
|
|
int exit_code);
|
|
|
|
void
|
|
|
|
weston_output_add_destroy_listener(struct weston_output *output,
|
|
|
|
struct wl_listener *listener);
|
|
|
|
struct wl_listener *
|
|
|
|
weston_output_get_destroy_listener(struct weston_output *output,
|
|
|
|
wl_notify_func_t notify);
|
|
|
|
int
|
|
|
|
weston_compositor_set_xkb_rule_names(struct weston_compositor *ec,
|
|
|
|
struct xkb_rule_names *names);
|
|
|
|
|
|
|
|
/* String literal of spaces, the same width as the timestamp. */
|
|
|
|
#define STAMP_SPACE " "
|
|
|
|
|
|
|
|
/**
|
|
|
|
* \ingroup wlog
|
|
|
|
*/
|
|
|
|
typedef int (*log_func_t)(const char *fmt, va_list ap);
|
|
|
|
void
|
|
|
|
weston_log_set_handler(log_func_t log, log_func_t cont);
|
|
|
|
int
|
|
|
|
weston_log(const char *fmt, ...)
|
|
|
|
__attribute__ ((format (printf, 1, 2)));
|
|
|
|
int
|
|
|
|
weston_log_continue(const char *fmt, ...)
|
|
|
|
__attribute__ ((format (printf, 1, 2)));
|
|
|
|
|
|
|
|
enum weston_screenshooter_outcome {
|
|
|
|
WESTON_SCREENSHOOTER_SUCCESS,
|
|
|
|
WESTON_SCREENSHOOTER_NO_MEMORY,
|
|
|
|
WESTON_SCREENSHOOTER_BAD_BUFFER
|
|
|
|
};
|
|
|
|
|
|
|
|
typedef void (*weston_screenshooter_done_func_t)(void *data,
|
|
|
|
enum weston_screenshooter_outcome outcome);
|
|
|
|
int
|
|
|
|
weston_screenshooter_shoot(struct weston_output *output, struct weston_buffer *buffer,
|
|
|
|
weston_screenshooter_done_func_t done, void *data);
|
|
|
|
struct weston_recorder *
|
|
|
|
weston_recorder_start(struct weston_output *output, const char *filename);
|
|
|
|
void
|
|
|
|
weston_recorder_stop(struct weston_recorder *recorder);
|
|
|
|
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
struct weston_view_animation;
|
|
|
|
typedef void (*weston_view_animation_done_func_t)(struct weston_view_animation *animation, void *data);
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
animation, shell: add kbd focus change animation
When enabled, this will make all but the keyboard-focused window dim.
Also the background gets dimmed, if there are any windows open. The
panel is not dimmed.
When the keyboard focus changes, the change in dimming is animated.
The dimming is implemented with transparent solid-color surfaces, two at
most. The net effect of two overlapping dim surfaces is kept constant
during animations (stable fade animation).
There is a new weston.ini option "focus-animation", that defaults to
none, and can be set to "dim-layer" to enable the focus change
animation.
[pq: Sliced, squashed, and rebased the patch series. Fixed surface alpha
interaction with the switcher. Wrote the commit message.]
[pochu: rebased, ported to weston_view]
11 years ago
|
|
|
void
|
|
|
|
weston_view_animation_destroy(struct weston_view_animation *animation);
|
|
|
|
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
struct weston_view_animation *
|
|
|
|
weston_zoom_run(struct weston_view *view, float start, float stop,
|
|
|
|
weston_view_animation_done_func_t done, void *data);
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
struct weston_view_animation *
|
|
|
|
weston_fade_run(struct weston_view *view,
|
|
|
|
float start, float end, float k,
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
weston_view_animation_done_func_t done, void *data);
|
|
|
|
|
|
|
|
struct weston_view_animation *
|
|
|
|
weston_move_scale_run(struct weston_view *view, int dx, int dy,
|
|
|
|
float start, float end, bool reverse,
|
|
|
|
weston_view_animation_done_func_t done, void *data);
|
|
|
|
|
|
|
|
struct weston_view_animation *
|
|
|
|
weston_move_run(struct weston_view *view, int dx, int dy,
|
|
|
|
float start, float end, bool reverse,
|
|
|
|
weston_view_animation_done_func_t done, void *data);
|
|
|
|
|
|
|
|
void
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
weston_fade_update(struct weston_view_animation *fade, float target);
|
|
|
|
|
animation, shell: add kbd focus change animation
When enabled, this will make all but the keyboard-focused window dim.
Also the background gets dimmed, if there are any windows open. The
panel is not dimmed.
When the keyboard focus changes, the change in dimming is animated.
The dimming is implemented with transparent solid-color surfaces, two at
most. The net effect of two overlapping dim surfaces is kept constant
during animations (stable fade animation).
There is a new weston.ini option "focus-animation", that defaults to
none, and can be set to "dim-layer" to enable the focus change
animation.
[pq: Sliced, squashed, and rebased the patch series. Fixed surface alpha
interaction with the switcher. Wrote the commit message.]
[pochu: rebased, ported to weston_view]
11 years ago
|
|
|
struct weston_view_animation *
|
|
|
|
weston_stable_fade_run(struct weston_view *front_view, float start,
|
|
|
|
struct weston_view *back_view, float end,
|
|
|
|
weston_view_animation_done_func_t done, void *data);
|
|
|
|
|
Split the geometry information from weston_surface out into weston_view
The weston_surface structure is split into two structures:
* The weston_surface structure storres everything required for a
client-side or server-side surface. This includes buffers; callbacks;
backend private data; input, damage, and opaque regions; and a few other
bookkeeping bits.
* The weston_view structure represents an entity in the scenegraph and
storres all of the geometry information. This includes clip region,
alpha, position, and the transformation list as well as all of the
temporary information derived from the geometry state. Because a view,
and not a surface, is a scenegraph element, the view is what is placed
in layers and planes.
There are a few things worth noting about the surface/view split:
1. This is *not* a modification to the protocol. It is, instead, a
modification to Weston's internal scenegraph to allow a single surface
to exist in multiple places at a time. Clients are completely unaware
of how many views to a particular surface exist.
2. A view is considered a direct child of a surface and is destroyed when
the surface is destroyed. Because of this, the view.surface pointer is
always valid and non-null.
3. The compositor's surface_list is replaced with a view_list. Due to
subsurfaces, building the view list is a little more complicated than
it used to be and involves building a tree of views on the fly whenever
subsurfaces are used. However, this means that backends can remain
completely subsurface-agnostic.
4. Surfaces and views both keep track of which outputs they are on.
5. The weston_surface structure now has width and height fields. These
are populated when a new buffer is attached before surface.configure
is called. This is because there are many surface-based operations
that really require the width and height and digging through the views
didn't work well.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
|
|
|
struct weston_view_animation *
|
|
|
|
weston_slide_run(struct weston_view *view, float start, float stop,
|
|
|
|
weston_view_animation_done_func_t done, void *data);
|
|
|
|
|
libweston, desktop-shell: Add a wrapper for weston_surface reference
Similar to how we do it with drm_fb ref counts, increase a reference
count and return the same object.
Plug-in in desktop-shell when we map up the view in order to survive a
weston_surface destruction.
Astute readers will notice that this patch removes weston_view_destroy()
while keeping the balance between removing and adding a
weston_surface_unref() call in desktop_shell_destroy_surface().
The reason is to let weston_surface_unref() handle destruction on its
own. If multiple references are taken, then weston_surface_unref()
doesn't destroy the view, it just decreases the reference, with
a latter call to weston_surface_unref() to determine if the view
should be destroyed as well. This situation happens if we have
close animation enabled, were we have more than one reference taken: one
when mapping the view/surface and when when the surface itself was created,
(what we call, a weak reference).
If only a single reference is taken (for instance if we don't have close
animations enabled) then this weston_surface_unref()
call is inert as that reference is not set-up, leaving libweston to
handle the view destruction.
Following that with a weston_view_destroy() explicit call would cause a
UAF as the view was previous destroyed by a weston_surface_unref() call.
A side-effect of not keeping the weston_view_destroy() call would
happen when tearing down the compositor. If close animations are enabled,
weston_surface_unref() would not destroy the view, and because
weston_view_destroy() no longer exists, we would still have the
view in the other layers by the time we check-up if layers
have views present.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
3 years ago
|
|
|
struct weston_surface *
|
|
|
|
weston_surface_ref(struct weston_surface *surface);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_surface_unref(struct weston_surface *surface);
|
|
|
|
|
|
|
|
int
|
|
|
|
weston_output_mode_switch_to_temporary(struct weston_output *output,
|
|
|
|
struct weston_mode *mode,
|
|
|
|
int32_t scale);
|
|
|
|
int
|
|
|
|
weston_output_mode_switch_to_native(struct weston_output *output);
|
|
|
|
|
|
|
|
int
|
|
|
|
weston_backend_init(struct weston_compositor *c,
|
|
|
|
struct weston_backend_config *config_base);
|
|
|
|
int
|
|
|
|
weston_module_init(struct weston_compositor *compositor);
|
|
|
|
|
|
|
|
void *
|
|
|
|
weston_load_module(const char *name, const char *entrypoint);
|
|
|
|
|
|
|
|
size_t
|
|
|
|
weston_module_path_from_env(const char *name, char *path, size_t path_len);
|
|
|
|
|
|
|
|
int
|
|
|
|
weston_parse_transform(const char *transform, uint32_t *out);
|
|
|
|
|
|
|
|
const char *
|
|
|
|
weston_transform_to_string(uint32_t output_transform);
|
|
|
|
|
|
|
|
struct weston_keyboard *
|
|
|
|
weston_seat_get_keyboard(struct weston_seat *seat);
|
|
|
|
|
|
|
|
struct weston_pointer *
|
|
|
|
weston_seat_get_pointer(struct weston_seat *seat);
|
|
|
|
|
|
|
|
struct weston_touch *
|
|
|
|
weston_seat_get_touch(struct weston_seat *seat);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_seat_set_keyboard_focus(struct weston_seat *seat,
|
|
|
|
struct weston_surface *surface);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_keyboard_send_keymap(struct weston_keyboard *kbd,
|
|
|
|
struct wl_resource *resource);
|
|
|
|
|
|
|
|
int
|
|
|
|
weston_compositor_load_xwayland(struct weston_compositor *compositor);
|
|
|
|
|
|
|
|
int
|
|
|
|
weston_compositor_load_color_manager(struct weston_compositor *compositor);
|
|
|
|
|
|
|
|
bool
|
|
|
|
weston_head_is_connected(struct weston_head *head);
|
|
|
|
|
|
|
|
bool
|
|
|
|
weston_head_is_enabled(struct weston_head *head);
|
|
|
|
|
|
|
|
bool
|
|
|
|
weston_head_is_device_changed(struct weston_head *head);
|
|
|
|
|
|
|
|
bool
|
|
|
|
weston_head_is_non_desktop(struct weston_head *head);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_head_reset_device_changed(struct weston_head *head);
|
|
|
|
|
|
|
|
const char *
|
|
|
|
weston_head_get_name(struct weston_head *head);
|
|
|
|
|
|
|
|
struct weston_output *
|
|
|
|
weston_head_get_output(struct weston_head *head);
|
|
|
|
|
|
|
|
uint32_t
|
|
|
|
weston_head_get_transform(struct weston_head *head);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_head_detach(struct weston_head *head);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_head_add_destroy_listener(struct weston_head *head,
|
|
|
|
struct wl_listener *listener);
|
|
|
|
|
|
|
|
struct wl_listener *
|
|
|
|
weston_head_get_destroy_listener(struct weston_head *head,
|
|
|
|
wl_notify_func_t notify);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_head_set_content_protection_status(struct weston_head *head,
|
|
|
|
enum weston_hdcp_protection status);
|
|
|
|
|
|
|
|
struct weston_head *
|
|
|
|
weston_compositor_iterate_heads(struct weston_compositor *compositor,
|
|
|
|
struct weston_head *iter);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_compositor_add_heads_changed_listener(struct weston_compositor *compositor,
|
|
|
|
struct wl_listener *listener);
|
|
|
|
|
|
|
|
struct weston_output *
|
|
|
|
weston_compositor_find_output_by_name(struct weston_compositor *compositor,
|
|
|
|
const char *name);
|
|
|
|
|
|
|
|
struct weston_output *
|
|
|
|
weston_compositor_create_output(struct weston_compositor *compositor,
|
|
|
|
struct weston_head *head, const char *name);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_output_destroy(struct weston_output *output);
|
|
|
|
|
|
|
|
int
|
|
|
|
weston_output_attach_head(struct weston_output *output,
|
|
|
|
struct weston_head *head);
|
|
|
|
|
|
|
|
struct weston_head *
|
|
|
|
weston_output_iterate_heads(struct weston_output *output,
|
|
|
|
struct weston_head *iter);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_output_set_scale(struct weston_output *output,
|
|
|
|
int32_t scale);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_output_set_transform(struct weston_output *output,
|
|
|
|
uint32_t transform);
|
|
|
|
|
|
|
|
bool
|
|
|
|
weston_output_set_color_profile(struct weston_output *output,
|
|
|
|
struct weston_color_profile *cprof);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_output_set_eotf_mode(struct weston_output *output,
|
|
|
|
enum weston_eotf_mode eotf_mode);
|
|
|
|
|
|
|
|
enum weston_eotf_mode
|
|
|
|
weston_output_get_eotf_mode(const struct weston_output *output);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_output_set_color_characteristics(struct weston_output *output,
|
|
|
|
const struct weston_color_characteristics *cc);
|
|
|
|
|
|
|
|
const struct weston_color_characteristics *
|
|
|
|
weston_output_get_color_characteristics(struct weston_output *output);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_output_init(struct weston_output *output,
|
|
|
|
struct weston_compositor *compositor,
|
|
|
|
const char *name);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_output_move(struct weston_output *output, int x, int y);
|
|
|
|
|
|
|
|
int
|
|
|
|
weston_output_enable(struct weston_output *output);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_output_disable(struct weston_output *output);
|
|
|
|
|
|
|
|
uint32_t
|
|
|
|
weston_output_get_supported_eotf_modes(struct weston_output *output);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_compositor_flush_heads_changed(struct weston_compositor *compositor);
|
|
|
|
|
|
|
|
struct weston_head *
|
|
|
|
weston_head_from_resource(struct wl_resource *resource);
|
|
|
|
|
|
|
|
struct weston_head *
|
|
|
|
weston_output_get_first_head(struct weston_output *output);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_output_allow_protection(struct weston_output *output,
|
|
|
|
bool allow_protection);
|
|
|
|
|
|
|
|
int
|
|
|
|
weston_compositor_enable_touch_calibrator(struct weston_compositor *compositor,
|
|
|
|
weston_touch_calibration_save_func save);
|
|
|
|
|
|
|
|
struct weston_log_context *
|
|
|
|
weston_log_ctx_create(void);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_log_ctx_destroy(struct weston_log_context *log_ctx);
|
|
|
|
|
|
|
|
int
|
|
|
|
weston_compositor_enable_content_protection(struct weston_compositor *compositor);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_timeline_refresh_subscription_objects(struct weston_compositor *wc,
|
|
|
|
void *object);
|
|
|
|
|
color: introduce weston_color_profile
Roughly speaking, a color profile describes the color space of content
or an output. Under the hood, the description includes one or more ways
to map colors between the profile space and some standard profile
connecting space (PCS).
This object is not called a color space. A color space has a unique
definition, while a color profile may contain multiple different
mappings depending on render intent. Some of these mappings may be
subjective, with an artistic touch.
When a source color profile and a destination color profile are combined
under a specific render intent, they produce a color transformation.
Color transformations are already preresented by weston_color_transform.
This patch adds the basic API for color profile objects. Everything
worthwhile of these objects is implemented in the color managers:
color-noop never creates these, and in color-lcms they are basically a
container for cmsHPROFILE, the Little CMS object for color profiles.
Color profile objects will not be interpreted outside of the color
managers, unlike color transformations.
For a start, the color manager API has one function to create color
profiles: from ICC profile data. More creation functions for other
sources will be added later.
The API has errmsg return parameter for error messages. These are not
simply weston_log()'d, because CM&HDR protocol will allow clients to
trigger errors and the protocol handles that gracefully. Therefore
instead of flooding the compositor logs, the error messages will
probably need to be relayed back to clients.
Color-lcms is expected to create a cmsHPROFILE for all kinds of color
profiles, not just for those created from ICC profile data. Hence,
color-lcms will fingerprint color profiles by the MD5 hash which Little
CMS computes for us. The fingerprint is used for de-duplication: instead
of creating copies, reference existing color profiles.
This code is very much based on Sebastian Wick's earlier work on Weston
color management, but structured and named differently.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
4 years ago
|
|
|
struct weston_color_profile *
|
|
|
|
weston_color_profile_ref(struct weston_color_profile *cprof);
|
|
|
|
|
|
|
|
void
|
|
|
|
weston_color_profile_unref(struct weston_color_profile *cprof);
|
|
|
|
|
|
|
|
const char *
|
|
|
|
weston_color_profile_get_description(struct weston_color_profile *cprof);
|
|
|
|
|
|
|
|
struct weston_color_profile *
|
|
|
|
weston_compositor_load_icc_file(struct weston_compositor *compositor,
|
|
|
|
const char *path);
|
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
#endif
|