On Fri, 13 Dec 2013 15:26:36 +0100
Maarten Baert wrote:
>
> - Why can the protocol only capture one screen at a time? I
> expect this will result in tearing because the screenshots won't
> correspond to the same point in time. Can this be avoided
> somehow? I realize that different outputs can h
From: Ander Conselvan de Oliveira
The call to weston_output_move() when creating the output is
unnecessary. That is already called by wesotn_output_init().
---
src/compositor-headless.c |2 --
src/compositor-rdp.c |2 --
2 files changed, 4 deletions(-)
diff --git a/src/compositor-h
From: Ander Conselvan de Oliveira
Set a flag when an output is being destroyed and use that to avoid
repainting. This allows functions that schedule an output repaint to
be called when the output is being destroyed without causing the
compositor to crash.
---
src/compositor.c |5 +
src/c
From: "Zhang, Xiong Y"
Previously, when an output was moved due to another output being
unplugged, the views on the first output would remain in the same
position.
This patch adds an output_move signal that the views listen too in
order to repostion themselves in the event of an unplug.
Signed-
From: "Zhang, Xiong Y"
If the saved position for a fullscreen or maximized output view is in an
output that has been unplugged, the coordinates don't make sense
anymore. In that case, invalidate them and use the initial position
algorithm when changing them back to the basic state.
Signed-off-by
From: "Zhang, Xiong Y"
Use the output destroy signal to move the views in the event the output
was unplugged.
Signed-off-by: Zhang, Xiong Y
Signed-off-by: Ander Conselvan de Oliveira
---
src/compositor.c | 59 --
src/compositor.h |1 +
From: Ander Conselvan de Oliveira
When a view is moved to another output because its current output was
unplugged, remove the fullscreen and maximized state.
---
desktop-shell/shell.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index f7
From: "Zhang, Xiong Y"
Instead of having the backends move the remaining outputs when one is
destroyed, let the core compositor deal with that.
Signed-off-by: Zhang, Xiong Y
Signed-off-by: Ander Conselvan de Oliveira
---
src/compositor-drm.c |8
src/compositor-x11.c | 20 +++--
From: Ander Conselvan de Oliveira
Previously, if a pointer was inside an output that was unplugged, it
could potentialy end up outside any valid output forever. With this
patch, the pointer is moved to the "closest" output to the pointer.
---
src/compositor.c | 15 +++
src/compositor.h
From: Ander Conselvan de Oliveira
Instead of terminating the compositor, destroy the output whose close
button was clicked and move the other outputs, as is done in the drm
backend.
---
src/compositor-x11.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
From: Ander Conselvan de Oliveira
When destroying ouputs, they would sometimes be removed before the call
to weston_output_destory() and sometimes after, depending on the
backend. Now the output is remove withing that function so the behavior
is standard across all backends.
---
src/compositor-d
Le 13/12/2013 18:57, Maarten Baert a écrit :
On 13/12/13 16:01, Martin Peres wrote:
I may be wrong, but other unix users shouldn't be able to
communicate with another user's compositor unless this
user specifically allowed that by adding him to his/her group.
Okay, then that's not an issue.
S
On Fri, Dec 13, 2013 at 12:57 PM, Maarten Baert
wrote:
> On 13/12/13 16:01, Martin Peres wrote:
> > I may be wrong, but other unix users shouldn't be able to
> > communicate with another user's compositor unless this
> > user specifically allowed that by adding him to his/her group.
> Okay, then t
On 13/12/13 16:01, Martin Peres wrote:
> I may be wrong, but other unix users shouldn't be able to
> communicate with another user's compositor unless this
> user specifically allowed that by adding him to his/her group.
Okay, then that's not an issue.
> Screenshot/screencapture applications are a
Le 04/12/2013 17:38, Sebastian Wick a écrit :
diff --git a/weston.ini.in b/weston.ini.in
index 5181a9e..bc32567 100644
--- a/weston.ini.in
+++ b/weston.ini.in
@@ -65,3 +65,6 @@ path=@libexecdir@/weston-keyboard
#constant_accel_factor = 50
#min_accel_factor = 0.16
#max_accel_factor = 1.0
+
+
2013/12/13 Maarten Baert :
> I'm trying to add Wayland support to a screen recording application, but
> I'm running into a few issues:
>
> - There is no official protocol. I'm using the weston-specific
> 'screenshooter' interface now, but I don't want to use a different
> interface for every possib
Le 13/12/2013 15:26, Maarten Baert a écrit :
I'm trying to add Wayland support to a screen recording application, but
I'm running into a few issues:
- There is no official protocol. I'm using the weston-specific
'screenshooter' interface now, but I don't want to use a different
interface for eve
I'm trying to add Wayland support to a screen recording application, but
I'm running into a few issues:
- There is no official protocol. I'm using the weston-specific
'screenshooter' interface now, but I don't want to use a different
interface for every possible Wayland compositor in the future. A
On Thu, 2013-12-12 at 18:23 -0600, Jason Ekstrand wrote:
> Elvis,
>
> On Dec 12, 2013 2:08 AM, "Elvis Lee(KwangWoong Lee)"
> wrote:
> > While using text protocol in Weston, we encountered some cases which
> exceeds the limitation.
> >
> > For example, "set_surrounding_text" carries a string which
19 matches
Mail list logo
