On Wed, Jun 26, 2013 at 06:08:46PM +0100, Rob Bradford wrote:
> From: Rob Bradford
>
> The list of surfaces used by weston_compositor_pick_surface() is
> maintained in list of surfaces stored on the compositor. This list is
> generated from the surfaces across all the layers using
> weston_compos
Hi,
On 5 July 2013 20:35, Thiago Macieira wrote:
> First, it mentions that Requires.private is *not* used in dynamic linking.
> Then it changes its mind with that last sentence, which is cryptic.
>
> In any case, the actual behaviour is that Requires.private is used in dynamic
> linking. It adds
Just a quick comment - I've been itching to rename wl_shell_surface so
something more concise, so I'd like to go with xdg_surface instead of
xdg_shell_surface.
Kristian
On Fri, Jul 5, 2013 at 3:39 PM, wrote:
> From: Rafael Antognolli
>
> xdg_shell is a protocol aimed to substitute wl_shell in
I'd prefer a flags argument instead of a bool prefer565 argument here.
Kristian
On Fri, Jul 5, 2013 at 5:41 AM, Tomeu Vizoso wrote:
> And check if the renderer supports the RGB565 format for wl_shm buffers
> before creating the cairo surface and requesting the buffer.
>
> It can save quite some
Could we add an wl_shm entry point to let the renderer add additional
supported formats to wl_shm instead?
Kristian
On Fri, Jul 5, 2013 at 5:41 AM, Tomeu Vizoso wrote:
> Hi,
>
> this patch series allows clients to request the creation of 16bit buffers,
> useful for conserving resources in device
On Fri, Jul 05, 2013 at 04:05:26PM +0300, Ander Conselvan de Oliveira wrote:
> From: Ander Conselvan de Oliveira
>
> Weston would crash when hot plugging/unplugging outputs using the DRM
> backend due to a corrupted plane list.
Hey Ander, thanks for fixing these. All patches look good and the
n
From: Rafael Antognolli
xdg_shell is a protocol aimed to substitute wl_shell in the long term,
but will not be part of the wayland core protocol. It starts as a
non-stable API, aimed to be used as a development place at first, and
once features are defined as required by several desktop shells, w
From: Rafael Antognolli
Hello all,
After some discussions about how to add some features to the wl_shell protocol
and how it would possibly break existing behavior, the idea of a xdg_shell
protocol appeared, similar to what ewmh is to X11. It would be a shell
interface defined by features needed
On 07/03/2013 03:35 PM, scsijon wrote:
we have seen this before with xorg servers, it's usually found that some
dependancy for the driver concerned has been updated, but the driver
itself hasn't been rebuilt to suit, usually fixed by either recompiling
the driver (if possible) or stepping back t
On sexta-feira, 5 de julho de 2013 09.26.23, Pekka Paalanen wrote:
> The color management modules are an example of a weston module, that
> does not need pixman at all. If you grep through src/cms*.[ch], there
> is not a single mention of "pixman". Why do these modules, if they were
> external, nee
From: Ander Conselvan de Oliveira
The panel and background were never created for hotplugged outputs and
since some parts of the code assume that they always exist that would
lead to desktop-shell client to crash in that case.
This was easier to spot when the display was locked, because Weston
r
From: Ander Conselvan de Oliveira
This lets the code for adding panel launchers and setting up the
background to be moved into panel_* and background_* functions.
Note that this changes the behavior of the default launcher. Before
this change a default launcher would be added only if there was n
From: Ander Conselvan de Oliveira
Weston would crash when hot plugging/unplugging outputs using the DRM
backend due to a corrupted plane list.
https://bugs.freedesktop.org/show_bug.cgi?id=66530
https://bugs.freedesktop.org/show_bug.cgi?id=66529
---
src/compositor.c |6 ++
1 file changed
---
src/pixman-renderer.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/pixman-renderer.c b/src/pixman-renderer.c
index b17c02f..c162292 100644
--- a/src/pixman-renderer.c
+++ b/src/pixman-renderer.c
@@ -560,6 +560,9 @@ pixman_renderer_attach(struct weston_surface *es, struct
weston
---
src/gl-renderer.c | 56 ---
1 file changed, 45 insertions(+), 11 deletions(-)
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index bfccd7b..cfeec55 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -1109,6 +1109,8 @@ gl_renderer_
---
src/rpi-bcm-stubs.h | 1 +
src/rpi-renderer.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/src/rpi-bcm-stubs.h b/src/rpi-bcm-stubs.h
index 4b89319..d3ffd4b 100644
--- a/src/rpi-bcm-stubs.h
+++ b/src/rpi-bcm-stubs.h
@@ -85,6 +85,7 @@ typedef enum
/* these are not the right v
So renderers can register wl_shm themselves in order to advertise
the formats that they support.
TODO: properly solve the naming conflict with wl_shm_create_pool
---
src/wayland-server.h | 5 +++--
src/wayland-shm.c| 35 ++-
2 files changed, 5 insertions(+), 3
So in the future each can announce the formats it supports.
TODO: properly fix the naming conflict with wl_shm_create_pool_xxx
---
src/compositor.c | 2 --
src/gl-renderer.c | 20
src/pixman-renderer.c | 22 ++
src/rpi-renderer.c| 20
And check if the renderer supports the RGB565 format for wl_shm buffers
before creating the cairo surface and requesting the buffer.
It can save quite some memory with big surfaces such as desktop
backgrounds.
---
clients/desktop-shell.c | 8
clients/keyboard.c | 2 +-
clients/tab
---
protocol/wayland.xml | 65 +++-
src/wayland-shm.c| 6 +
2 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 1442b6a..3cfa953 100644
--- a/protocol/wayland.xml
+++ b/protocol/wa
Hi,
this patch series allows clients to request the creation of 16bit buffers,
useful for conserving resources in devices with constrained resources when
using big surfaces such as desktop background images.
I'm asking for ideas about what to do with how renderers are now
registering wl_shm, need
21 matches
Mail list logo
