Signed-off-by: Siddharth Heroor
---
README |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/README b/README
index 5f85888..ca26cc0 100644
--- a/README
+++ b/README
@@ -3,7 +3,7 @@ What is Wayland
Wayland is a project to define a protocol for a compositor to talk to
Update the bug link. Thanks to Rune K. Svendsen for spotting this.
---
configure.ac |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index d553eae..0ef2ae1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,7 +1,7 @@
AC_PREREQ([2.64])
AC_INIT([we
The product name is wayland, the component name is weston.
---
configure.ac |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index d553eae..796bc47 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,7 +1,7 @@
AC_PREREQ([2.64])
AC_INIT([weston],
Through trial-and-error editing the config file, I've found that this is
caused by the "keymap_layout=en" line in weston.ini. No freeze when this is
commented out.
Because of this line weston tries to read /usr/share/X11/xkb/symbols/en
which doesn't exist, and it freezes, or at least makes me unab
On 02/13/2013 10:25 AM, Pekka Paalanen wrote:
On Tue, 12 Feb 2013 18:37:50 +
Rob Bradford wrote:
On 12 February 2013 15:52, Ander Conselvan de Oliveira
wrote:
Input device initialization takes several microseconds to complete. Two
milliseconds, I assume :-)
things causes this: compil
This introduces the function widget_cairo_create().
Instead of directly referencing surface->cairo_surface, use the function
widget_cairo_create(), which will create the cairo_surface as necessary,
and just returns a Cairo drawing context. Also fix window_get_surface()
similarly.
Now we can go th
Menu and tooltip redraw functions were using the surface size directly.
For consistency, make them use the widget size instead, it is the same.
Signed-off-by: Pekka Paalanen
---
clients/window.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/clients/window.c b
This flag was always true, and never false.
Signed-off-by: Pekka Paalanen
---
clients/window.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index 17f13b9..2260b87 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -219,7 +219,6 @@ struct window
Widgets should be rendering to a cairo_surface for a particular
wl_surface, just like buffers are per surface.
window_flush() has a change in behaviour: it will now send
wl_shell_surface.set_toplevel also without a cairo_surface to be
attached. This shouldn't change anything in practice.
Signed-o
So that given a widget, we can access the surface specific data, like
buffers, and input and opaque regions.
Signed-off-by: Pekka Paalanen
---
clients/window.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index ecc38b0..9ebd
They are per wl_surface state.
The frame widget is always on the main surface, since it can be created
only for the window. That is why frame_resize_handler() can simply
assume that the surface is the main_surface.
Signed-off-by: Pekka Paalanen
---
clients/window.c | 114 +++
Repaint and resizing widget recursions must start from the root widget
of each (sub-)surface, so that buffers and regions get initialized
correctly. Make it easier by moving the widget field from struct window
to struct surface.
Signed-off-by: Pekka Paalanen
---
clients/window.c | 29 +++
Not used elsewhere, just cleanup.
Signed-off-by: Pekka Paalanen
---
clients/window.c | 39 +++
1 file changed, 15 insertions(+), 24 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index 0185dd2..854408c 100644
--- a/clients/window.c
+++ b/client
These are surface specifics, since buffers are surface specific.
SURFACE_HINT_RESIZE is moved together to the other SURFACE_* flags, so
that surface_create_surface() would not need two flags arguments.
struct toysurface::prepare vfunc checks for SURFACE_HINT_RESIZE, and
egl_window_surface_create()
Fields 'allocation' and 'server_allocation' are surface specific. Fields
'saved_allocation', 'min_allocation', and 'pending_allocation' are
window specific, and will not be moved.
Field 'toysurface' is naturally surface specific, since it provides the
backing storage for the wl_surface.
Signed-of
Struct window has many fields that are directly related to the
wl_surface, more than to the window as a whole. When we start composing
a window from several wl_surfaces, these fields need to be per
wl_surface, not per window.
Start separating such fields from struct window into struct surface by
m
Handle the case when we the compositor somehow migrates from requiring
double buffering into working on single buffering, so we release the
extra shm buffer.
Currently, I do not think this can happen in practice, but in the future
it may happen with sub-surfaces.
Signed-off-by: Pekka Paalanen
--
Hi Kristian,
this series prepares toytoolkit for sub-surfaces by moving
fields from struct window to a new per-wl_surface struct.
It also contains other cleanups. The purpose is just to make
implementing sub-surface support easier.
This series does not add any sub-surface featurea, does not
requi
When fading in, if a repaint was triggered after a call to
weston_compositor_fade() but before the first call to fade_frame(),
the fade surface wouldn't be drawn because its alpha channel wasn't
initialized properly.
---
src/compositor.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
The page flip event timestamps comes from the monotonic clock, while
idle_repaint() gets the time with gettimeofday(). That leads to
inconsistent timestamps on the frame callbacks.
Fix this by making the drm backend page flip to the current buffer and
call weston_output_finish_frame() with the pag
On Tue, 12 Feb 2013 18:37:50 +
Rob Bradford wrote:
> On 12 February 2013 15:52, Ander Conselvan de Oliveira
> wrote:
> > Input device initialization takes several microseconds to complete. Two
milliseconds, I assume :-)
> > things causes this: compiling the XKB keymap and reading the prope
On Tue, 12 Feb 2013 17:45:12 -0800
Nick Kisialiou wrote:
> Actually, there is a value in clients that need 2 shells at the same time.
> Think about an SDK or a development environment for a phone OS. The
> development environment would work in a desktop shell because it is more
> convenient for d
22 matches
Mail list logo
