mainnika
/
weston
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1315 Commits
1 Branch
0 Tags
13 MiB
Tag: Branch: Tree: 0e4452e02a
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '0e4452e02a'
${ noResults }
weston/src/compositor.h

481 lines
13 KiB
Raw Normal View History Unescape

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
Collabora copyright updates which I forgot to add while working on these files. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
* Copyright © 2012 Collabora, Ltd.
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 to use, copy, modify, distribute, and sell this software and
* its documentation for any purpose is hereby granted without fee, provided
* that the above copyright notice appear in all copies and that both that
* copyright notice and this permission notice appear in supporting
* documentation, and that the name of the copyright holders not be used in
* advertising or publicity pertaining to distribution of the software
* without specific, written prior permission. The copyright holders make
* no representations about the suitability of this software for any
* purpose. It is provided "as is" without express or implied warranty.
*
* THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
* SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
* FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
* SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
* RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
* CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
#ifndef _WAYLAND_SYSTEM_COMPOSITOR_H_
#define _WAYLAND_SYSTEM_COMPOSITOR_H_
#include <libudev.h>
#include <pixman.h>
#include <wayland-server.h>
#include <GLES2/gl2.h>
#include <GLES2/gl2ext.h>
#include <EGL/egl.h>
#include <EGL/eglext.h>
compositor: move matrix code to separate files Move matrix code to separate files to allow writing unit tests for it. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
#include "matrix.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
struct weston_transform {
struct weston_matrix matrix;
compositor: implement a stack of surface transformations Having at most one transformation object attached to a surface is not enough anymore. If we have a surface that needs to be scaled to fullscreen, and then we have the zoom animation, we already need two transformations combined. Implement support for multiple transformations by adding a transformation list. The final transformation is the ordered composite of those in the list. To avoid traversing the list every single time, add a dirty flag, and cache the final transformation. The existing transformation users (only zoom) are converted. Note: surface drawing should honour all kinds of transformations, but not damage region code nor input event translating code take transformations into account, AFAICT. Therefore anything but translation will probably behave badly until they are fixed. Cc: Juan Zhao <juan.j.zhao@linux.intel.com> Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
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
};
struct weston_surface;
struct weston_input_device;
struct weston_mode {
uint32_t flags;
int32_t width, height;
uint32_t refresh;
struct wl_list link;
};
struct weston_output {
struct wl_list link;
struct weston_compositor *compositor;
struct weston_matrix matrix;
struct wl_list frame_callback_list;
int32_t x, y, mm_width, mm_height;
pixman_region32_t region;
pixman_region32_t previous_damage;
uint32_t flags;
int repaint_needed;
int repaint_scheduled;
char *make, *model;
uint32_t subpixel;
struct weston_mode *current;
struct wl_list mode_list;
compositor: Move repaint loop into a backend function We've trimmed down the actual repaint loop to just iterating through the surface list and calling weston_surface_draw(), so we push that to the backend without too much code duplication.
13 years ago
void (*repaint)(struct weston_output *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
int (*set_hardware_cursor)(struct weston_output *output,
struct weston_input_device *input);
void (*destroy)(struct weston_output *output);
};
struct weston_input_device {
struct wl_input_device input_device;
struct weston_compositor *compositor;
struct weston_surface *sprite;
int32_t hotspot_x, hotspot_y;
struct wl_list link;
uint32_t modifier_state;
compositor: Compute overlapped early and base hw cursor decision on that
13 years ago
int hw_cursor;
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 num_tp;
struct wl_surface *touch_focus;
struct wl_listener touch_focus_listener;
struct wl_resource *touch_focus_resource;
struct wl_listener touch_focus_resource_listener;
};
enum weston_visual {
WESTON_NONE_VISUAL,
WESTON_ARGB_VISUAL,
WESTON_RGB_VISUAL
};
struct weston_shader {
GLuint program;
GLuint vertex_shader, fragment_shader;
GLuint proj_uniform;
GLuint tex_uniform;
GLuint alpha_uniform;
GLuint color_uniform;
compositor: honour repaint regions with transformed surfaces Previously, if a surface was transformed, it repainted as a whole, regardless of the computed repaint region. As damage regions determine repaint regions and whether a surface is considered for drawing at all, this lead to disappearing surfaces if all surfaces were considered transformed. Also transparent transformed surfaces were redrawn without the surfaces below being properly redrawn, leading to alpha-saturation. Fix that by making texture_region() use the proper global-to-surface coordinate transformation for texture coordinates. This makes it possible to call texture_region() also for transformed surfaces. As texture coordinates may now lie outside the valid texture image, the fragment shader is modified to check the fragment texture coordinates. The special path texture_transformed_surface() is no longer used and is removed. This change fixes many of the rendering artifacts related to transformed surfaces. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
GLuint texwidth_uniform;
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_animation {
void (*frame)(struct weston_animation *animation,
struct weston_output *output, uint32_t msecs);
struct wl_list link;
};
struct weston_spring {
double k;
double friction;
double current;
double target;
double previous;
uint32_t timestamp;
};
struct weston_shell {
void (*lock)(struct weston_shell *shell);
void (*unlock)(struct weston_shell *shell);
void (*map)(struct weston_shell *shell, struct weston_surface *surface,
int32_t width, int32_t height);
void (*configure)(struct weston_shell *shell,
struct weston_surface *surface,
int32_t x, int32_t y, int32_t width, int32_t height);
Merge remote-tracking branch 'pq/compositor-dtors-v1' This collided with the big weston rename, but git did a good job of fixing most cases. Conflicts: compositor/compositor.h src/compositor-x11.c src/compositor.c src/screenshooter.c src/util.c
13 years ago
void (*destroy)(struct weston_shell *shell);
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,
WESTON_COMPOSITOR_IDLE, /* shell->unlock called on activity */
WESTON_COMPOSITOR_SLEEPING /* no rendering, no frame events */
};
Merge remote-tracking branch 'pq/compositor-dtors-v1' This collided with the big weston rename, but git did a good job of fixing most cases. Conflicts: compositor/compositor.h src/compositor-x11.c src/compositor.c src/screenshooter.c src/util.c
13 years ago
struct screenshooter;
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_shm *shm;
struct weston_xserver *wxs;
EGLDisplay display;
EGLContext context;
EGLConfig config;
GLuint fbo;
uint32_t current_alpha;
struct weston_shader texture_shader;
struct weston_shader solid_shader;
compositor: Move shader setup to weston_surface_draw()
13 years ago
struct weston_shader *current_shader;
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_shell *shell;
/* There can be more than one, but not right now... */
struct wl_input_device *input_device;
struct wl_list output_list;
struct wl_list input_device_list;
struct wl_list surface_list;
struct wl_list binding_list;
struct wl_list animation_list;
struct {
struct weston_spring spring;
struct weston_animation animation;
compositor: Keep fade surface around while we're fading This removes more special cases from weston_output_repaint() and we avoid creating and destroying the surface for each animation frame. We gain another special case in weston_compositor_top(), but that's less of a problem, and we'll fix that later.
13 years ago
struct weston_surface *surface;
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
} fade;
uint32_t state;
struct wl_event_source *idle_source;
uint32_t idle_inhibit;
int option_idle_time; /* default timeout, s */
int idle_time; /* effective timeout, s */
/* Repaint state. */
struct timespec previous_swap;
struct wl_array vertices, indices;
struct weston_surface *overlay;
struct weston_switcher *switcher;
uint32_t focus;
PFNGLEGLIMAGETARGETRENDERBUFFERSTORAGEOESPROC
image_target_renderbuffer_storage;
PFNGLEGLIMAGETARGETTEXTURE2DOESPROC image_target_texture_2d;
PFNEGLCREATEIMAGEKHRPROC create_image;
PFNEGLDESTROYIMAGEKHRPROC destroy_image;
PFNEGLBINDWAYLANDDISPLAYWL bind_display;
PFNEGLUNBINDWAYLANDDISPLAYWL unbind_display;
int has_bind_display;
void (*destroy)(struct weston_compositor *ec);
int (*authenticate)(struct weston_compositor *c, uint32_t id);
EGLImageKHR (*create_cursor_image)(struct weston_compositor *c,
int32_t *width, int32_t *height);
Merge remote-tracking branch 'pq/compositor-dtors-v1' This collided with the big weston rename, but git did a good job of fixing most cases. Conflicts: compositor/compositor.h src/compositor-x11.c src/compositor.c src/screenshooter.c src/util.c
13 years ago
struct screenshooter *screenshooter;
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
};
#define MODIFIER_CTRL (1 << 8)
#define MODIFIER_ALT (1 << 9)
#define MODIFIER_SUPER (1 << 10)
enum weston_output_flags {
WL_OUTPUT_FLIPPED = 0x01
};
struct weston_surface {
struct wl_surface surface;
struct weston_compositor *compositor;
compositor: Drop unused saved_texture surface field
13 years ago
GLuint texture;
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 damage;
pixman_region32_t opaque;
int32_t pitch;
struct wl_list link;
struct wl_list buffer_link;
compositor: Move shader setup to weston_surface_draw()
13 years ago
struct weston_shader *shader;
GLfloat color[4];
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 alpha;
uint32_t visual;
compositor: Compute whether or not a surface is overlapped
13 years ago
int overlapped;
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: restructure weston_surface::transform Separate mutable data and cached immutable data in struct weston_surface. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
/* Surface geometry state, mutable.
* If you change anything, set dirty = 1.
* That includes the transformations referenced from the list.
*/
compositor: implement a stack of surface transformations Having at most one transformation object attached to a surface is not enough anymore. If we have a surface that needs to be scaled to fullscreen, and then we have the zoom animation, we already need two transformations combined. Implement support for multiple transformations by adding a transformation list. The final transformation is the ordered composite of those in the list. To avoid traversing the list every single time, add a dirty flag, and cache the final transformation. The existing transformation users (only zoom) are converted. Note: surface drawing should honour all kinds of transformations, but not damage region code nor input event translating code take transformations into account, AFAICT. Therefore anything but translation will probably behave badly until they are fixed. Cc: Juan Zhao <juan.j.zhao@linux.intel.com> Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
struct {
compositor: move weston_surface::x,y into geometry weston_surface::transform.position depends on x,y, and therefore the dirty flag, so move x and y into geometry. Also add the missing dirty flags. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
int32_t x, y; /* surface translation on display */
compositor: move weston_surface::width,height into geometry weston_surface::transform.boundingbox depends on width and height, and therefore geometry.dirty flag, so move width and height into geometry. Fix all users and check that the dirty flag is set. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
int32_t width, height;
compositor: move weston_surface::x,y into geometry weston_surface::transform.position depends on x,y, and therefore the dirty flag, so move x and y into geometry. Also add the missing dirty flags. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
compositor: restructure weston_surface::transform Separate mutable data and cached immutable data in struct weston_surface. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
/* struct weston_transform */
struct wl_list transformation_list;
compositor: implement a stack of surface transformations Having at most one transformation object attached to a surface is not enough anymore. If we have a surface that needs to be scaled to fullscreen, and then we have the zoom animation, we already need two transformations combined. Implement support for multiple transformations by adding a transformation list. The final transformation is the ordered composite of those in the list. To avoid traversing the list every single time, add a dirty flag, and cache the final transformation. The existing transformation users (only zoom) are converted. Note: surface drawing should honour all kinds of transformations, but not damage region code nor input event translating code take transformations into account, AFAICT. Therefore anything but translation will probably behave badly until they are fixed. Cc: Juan Zhao <juan.j.zhao@linux.intel.com> Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
int dirty;
compositor: restructure weston_surface::transform Separate mutable data and cached immutable data in struct weston_surface. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
} geometry;
compositor: implement a stack of surface transformations Having at most one transformation object attached to a surface is not enough anymore. If we have a surface that needs to be scaled to fullscreen, and then we have the zoom animation, we already need two transformations combined. Implement support for multiple transformations by adding a transformation list. The final transformation is the ordered composite of those in the list. To avoid traversing the list every single time, add a dirty flag, and cache the final transformation. The existing transformation users (only zoom) are converted. Note: surface drawing should honour all kinds of transformations, but not damage region code nor input event translating code take transformations into account, AFAICT. Therefore anything but translation will probably behave badly until they are fixed. Cc: Juan Zhao <juan.j.zhao@linux.intel.com> Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
compositor: restructure weston_surface::transform Separate mutable data and cached immutable data in struct weston_surface. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
/* State derived from geometry state, read-only.
* This is updated by weston_surface_update_transform().
*/
struct {
compositor: add weston_surface bounding box Compute a surface bounding box, especially for transformed surfaces, for which one cannot simply use x,y,width,height. The bounding box depends on width and height, so these are now under the geometry.dirty flag. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
pixman_region32_t boundingbox;
compositor: restructure weston_surface::transform Separate mutable data and cached immutable data in struct weston_surface. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
/* matrix and inverse are used only if enabled = 1.
* If enabled = 0, use x, y, width, height directly.
*/
int enabled;
compositor: drop inverse matrix from weston_transform Remove the inverse matrix member from struct weston_transform. It is easier (and probably faster, too) to create and store only forward transformation matrices in a list, multiply them once, and then invert the final matrix, rather than creating both forward and inverse matrices, and multiplying both. Add a stub for the 4x4 matrix inversion function. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
struct weston_matrix matrix;
compositor: simplify the matrix inversion API The compositor will likely do an order of magnitude less matrix inversions than point transformations with an inverse, hence we do not really need the optimised path for single-shot invert-and-transform. Expose only the computing of the explicit inverse matrix in the API. However, the matrix inversion tests need access to the internal functions. Designate a unit test build by #defining UNIT_TEST, and export the internal functions in that case. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
struct weston_matrix inverse;
compositor: make position a surface transformation Put the surface translation (absolute position) into the surface transformations list. This allows to set additional transformations before and after the global translation. Having the translation cached, changing the surface x,y now requires to set the geometry.dirty flag. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
struct weston_transform position; /* matrix from x, y */
compositor: implement a stack of surface transformations Having at most one transformation object attached to a surface is not enough anymore. If we have a surface that needs to be scaled to fullscreen, and then we have the zoom animation, we already need two transformations combined. Implement support for multiple transformations by adding a transformation list. The final transformation is the ordered composite of those in the list. To avoid traversing the list every single time, add a dirty flag, and cache the final transformation. The existing transformation users (only zoom) are converted. Note: surface drawing should honour all kinds of transformations, but not damage region code nor input event translating code take transformations into account, AFAICT. Therefore anything but translation will probably behave badly until they are fixed. Cc: Juan Zhao <juan.j.zhao@linux.intel.com> Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
} 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
/*
* Which output to vsync this surface to.
* Used to determine, whether to send or queue frame events.
* Must be NULL, if 'link' is not in weston_compositor::surface_list.
*/
struct weston_output *output;
struct weston_output *fullscreen_output;
struct wl_list frame_callback_list;
EGLImageKHR image;
struct wl_buffer *buffer;
struct wl_listener buffer_destroy_listener;
};
shell: add key binding for rotating a surface Add the key binding Super+Alt+MouseLeftButton to start rotating a surface by dragging. The rotation is removed, when the drag is near the rotation origin. Rotated surface are a stress test for input event coordinate transformations, damage region tracking, draw transformations, and window move and resize orientation. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
void
weston_surface_update_transform(struct weston_surface *surface);
compositor: rewrite draw and input coordinate transformations For unifying the coordinate system handling, introduce functions for converting explicitly between the global and the surface local coordinate systems. Use these functions in the input path, replacing weston_surface_transform(). In the draw path, rewrite transform_vertex() to take in surface local coordinates. As shell now uses the new functions, the rotation origin is properly placed in the middle of the surface. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
void
weston_surface_to_global(struct weston_surface *surface,
int32_t sx, int32_t sy, int32_t *x, int32_t *y);
void
weston_surface_from_global(struct weston_surface *surface,
int32_t x, int32_t y, int32_t *sx, int32_t *sy);
Use new grab api
13 years ago
void
weston_device_repick(struct wl_input_device *device, uint32_t 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_spring_init(struct weston_spring *spring,
double k, double current, double target);
void
weston_spring_update(struct weston_spring *spring, uint32_t msec);
int
weston_spring_done(struct weston_spring *spring);
void
weston_surface_activate(struct weston_surface *surface,
struct weston_input_device *device, uint32_t time);
compositor: Move repaint loop into a backend function We've trimmed down the actual repaint loop to just iterating through the surface list and calling weston_surface_draw(), so we push that to the backend without too much code duplication.
13 years ago
void
weston_surface_draw(struct weston_surface *es, struct weston_output *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
void
notify_motion(struct wl_input_device *device,
uint32_t time, int x, int y);
void
notify_button(struct wl_input_device *device,
uint32_t time, int32_t button, int32_t state);
void
notify_key(struct wl_input_device *device,
uint32_t time, uint32_t key, uint32_t state);
void
notify_pointer_focus(struct wl_input_device *device,
uint32_t time,
struct weston_output *output,
int32_t x, int32_t y);
void
notify_keyboard_focus(struct wl_input_device *device,
uint32_t time, struct weston_output *output,
struct wl_array *keys);
void
notify_touch(struct wl_input_device *device, uint32_t time, int touch_id,
int x, int y, int touch_type);
void
weston_output_finish_frame(struct weston_output *output, int msecs);
void
weston_output_damage(struct weston_output *output);
Use new grab api
13 years ago
struct weston_surface *
weston_compositor_pick_surface(struct weston_compositor *compositor,
int32_t x, int32_t y, int32_t *sx, int32_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
void
weston_compositor_repick(struct weston_compositor *compositor);
void
weston_compositor_schedule_repaint(struct weston_compositor *compositor);
void
weston_compositor_fade(struct weston_compositor *compositor, float tint);
void
weston_compositor_damage_all(struct weston_compositor *compositor);
void
weston_compositor_unlock(struct weston_compositor *compositor);
void
weston_compositor_wake(struct weston_compositor *compositor);
void
weston_compositor_activity(struct weston_compositor *compositor);
struct weston_binding;
typedef void (*weston_binding_handler_t)(struct wl_input_device *device,
uint32_t time, uint32_t key,
uint32_t button,
uint32_t state, void *data);
struct weston_binding *
weston_compositor_add_binding(struct weston_compositor *compositor,
uint32_t key, uint32_t button, uint32_t modifier,
weston_binding_handler_t binding, void *data);
void
weston_binding_destroy(struct weston_binding *binding);
Merge remote-tracking branch 'pq/compositor-dtors-v1' This collided with the big weston rename, but git did a good job of fixing most cases. Conflicts: compositor/compositor.h src/compositor-x11.c src/compositor.c src/screenshooter.c src/util.c
13 years ago
void
weston_binding_list_destroy_all(struct wl_list *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
void
weston_compositor_run_binding(struct weston_compositor *compositor,
struct weston_input_device *device,
uint32_t time,
uint32_t key, uint32_t button, int32_t state);
compositor: Compute overlapped early and base hw cursor decision on that
13 years ago
struct wl_list *
weston_compositor_top(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
struct weston_surface *
compositor: Only set surface geometry through weston_surface_configure() There are too many things to keep track of now, so let's require going through this.
13 years ago
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
void
weston_surface_configure(struct weston_surface *surface,
int x, int y, int width, int height);
void
weston_surface_assign_output(struct weston_surface *surface);
void
weston_surface_damage(struct weston_surface *surface);
void
weston_surface_damage_below(struct weston_surface *surface);
void
weston_surface_damage_rectangle(struct weston_surface *surface,
int32_t x, int32_t y,
int32_t width, int32_t height);
compositor: Move tracking of scanout buffers to compositor-drm
13 years ago
void
weston_buffer_post_release(struct wl_buffer *buffer);
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
weston_compositor_get_time(void);
int
weston_compositor_init(struct weston_compositor *ec, struct wl_display *display);
void
weston_compositor_shutdown(struct weston_compositor *ec);
void
weston_output_move(struct weston_output *output, int x, int y);
void
weston_output_init(struct weston_output *output, struct weston_compositor *c,
int x, int y, int width, int height, uint32_t flags);
void
weston_output_destroy(struct weston_output *output);
void
weston_input_device_init(struct weston_input_device *device,
struct weston_compositor *ec);
Merge remote-tracking branch 'pq/compositor-dtors-v1' This collided with the big weston rename, but git did a good job of fixing most cases. Conflicts: compositor/compositor.h src/compositor-x11.c src/compositor.c src/screenshooter.c src/util.c
13 years ago
void
weston_input_device_release(struct weston_input_device *device);
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_switcher_init(struct weston_compositor *compositor);
enum {
TTY_ENTER_VT,
TTY_LEAVE_VT
};
typedef void (*tty_vt_func_t)(struct weston_compositor *compositor, int event);
struct tty *
tty_create(struct weston_compositor *compositor,
tty_vt_func_t vt_func, int tty_nr);
void
tty_destroy(struct tty *tty);
Merge remote-tracking branch 'pq/compositor-dtors-v1' This collided with the big weston rename, but git did a good job of fixing most cases. Conflicts: compositor/compositor.h src/compositor-x11.c src/compositor.c src/screenshooter.c src/util.c
13 years ago
struct screenshooter *
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
screenshooter_create(struct weston_compositor *ec);
Merge remote-tracking branch 'pq/compositor-dtors-v1' This collided with the big weston rename, but git did a good job of fixing most cases. Conflicts: compositor/compositor.h src/compositor-x11.c src/compositor.c src/screenshooter.c src/util.c
13 years ago
void
screenshooter_destroy(struct screenshooter *s);
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 *
weston_load_image(const char *filename,
int32_t *width_arg, int32_t *height_arg,
uint32_t *stride_arg);
struct weston_process;
typedef void (*weston_process_cleanup_func_t)(struct weston_process *process,
int status);
struct weston_process {
pid_t pid;
weston_process_cleanup_func_t cleanup;
struct wl_list link;
};
struct wl_client *
weston_client_launch(struct weston_compositor *compositor,
struct weston_process *proc,
const char *path,
weston_process_cleanup_func_t cleanup);
void
weston_watch_process(struct weston_process *process);
int
weston_xserver_init(struct weston_compositor *compositor);
void
weston_xserver_destroy(struct weston_compositor *compositor);
void
weston_xserver_surface_activate(struct weston_surface *surface);
void
weston_xserver_set_selection(struct weston_input_device *device);
struct weston_zoom;
typedef void (*weston_zoom_done_func_t)(struct weston_zoom *zoom, void *data);
struct weston_zoom *
weston_zoom_run(struct weston_surface *surface, GLfloat start, GLfloat stop,
weston_zoom_done_func_t done, void *data);
#endif