___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Tue, 13 Feb 2018 15:57:33 +
Daniel Stone wrote:
> Hi Pekka,
>
> On 13 February 2018 at 14:21, Pekka Paalanen wrote:
> > /home/pq/git/weston/desktop-shell/shell.c: In function
> > ‘shell_output_destroy_move_layer’:
> > /home/pq/git/weston/desktop-shell/shell
Hi Pekka,
On 13 February 2018 at 14:21, Pekka Paalanen wrote:
> /home/pq/git/weston/desktop-shell/shell.c: In function
> ‘shell_output_destroy_move_layer’:
> /home/pq/git/weston/desktop-shell/shell.c:4718:24: warning: unused variable
> ‘output’ [-Wunused-variable]
> struc
: [PATCH weston] desktop-shell: fix shell_output_destroy_move_layer
unused variable
From: Pekka Paalanen
/home/pq/git/weston/desktop-shell/shell.c: In function
‘shell_output_destroy_move_layer’:
/home/pq/git/weston/desktop-shell/shell.c:4718:24: warning: unused variable
‘output’ [-Wunused-variable
From: Pekka Paalanen
/home/pq/git/weston/desktop-shell/shell.c: In function
‘shell_output_destroy_move_layer’:
/home/pq/git/weston/desktop-shell/shell.c:4718:24: warning: unused variable
‘output’ [-Wunused-variable]
struct weston_output *output = data;
Since the data pointer is not used for
Hi Marius,
On 8 February 2018 at 16:46, Marius Vlad wrote:
> Our case is when the view is the same as output being disabled/disconnected.
> There's not need to check the views' output with the output being disabled
> because weston_view_assign_output() already changes the output of the view
> wh
Our case is when the view is the same as output being disabled/disconnected.
There's not need to check the views' output with the output being disabled
because weston_view_assign_output() already changes the output of the view when
the output has been disabled/disconnected hence the check is not ne
On Wed, 31 Jan 2018 15:15:45 +0900
Tomohito Esaki wrote:
> There may be race condition between destroying surface and destroying
> output. If handle_output_destroy() is called after surface is destroyed,
> illegal memory access occurs when surface destroy signals is
> unregistered from the panel/
There may be race condition between destroying surface and destroying
output. If handle_output_destroy() is called after surface is destroyed,
illegal memory access occurs when surface destroy signals is
unregistered from the panel/background. This patch fixes this issue and
removes unnecessary ini
From: Bastian Farkas
Function names and structs changed.
Signed-off-by: Bastian Farkas
---
desktop-shell/shell.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 54ee4a2..1dae736 100644
--- a/
From: Bastian Farkas
Function names and structs changed.
Signed-off-by: Bastian Farkas
---
desktop-shell/shell.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 54ee4a2..1dae736 100644
--- a/
Function names and structs changed.
Signed-off-by: Bastian Farkas
---
desktop-shell/shell.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 54ee4a2..1dae736 100644
--- a/desktop-shell/shell.c
+
On 18/09/2017, 12.58, "Pekka Paalanen" wrote:
>
> On Fri, 15 Sep 2017 09:12:38 +0300
> Ian Ray wrote:
>
> > Support for kiosk-style use cases where binding modififer is `none':
> >
> > - Use binding modifier instead of hard-coded MODIFIER_SUPER for zoom.
> > - Disable opacity zoom if there i
On Fri, 15 Sep 2017 09:12:38 +0300
Ian Ray wrote:
> Support for kiosk-style use cases where binding modififer is `none':
>
> - Use binding modifier instead of hard-coded MODIFIER_SUPER for zoom.
> - Disable opacity zoom if there is no binding modifier.
>
Hello Ian,
strictly speaking, as you
Support for kiosk-style use cases where binding modififer is `none':
- Use binding modifier instead of hard-coded MODIFIER_SUPER for zoom.
- Disable opacity zoom if there is no binding modifier.
Signed-off-by: Ian Ray
---
desktop-shell/shell.c | 16 ++--
1 file changed, 10 inserti
On 7/28/17 2:11 PM, Philipp Kerling wrote:
xdg_shell requires this information to be shared with the client in
order to conform with the specification.
The code to forward this to the client by way of a configure() event
is already in place and works fine, it was just never being used until
now.
xdg_shell requires this information to be shared with the client in
order to conform with the specification.
The code to forward this to the client by way of a configure() event
is already in place and works fine, it was just never being used until
now.
Signed-off-by: Philipp Kerling
---
deskto
During a maximize event, a surface was previously always put back to
the primary output after one frame on the correct output, while keeping
its size. This was due to unset_maximized() resetting the output of
the shell surface to the primary output whenever the surface received a
commit.
This fix
On 3/25/17 4:42 PM, Raúl Peñacoba wrote:
Signed-off-by: Raúl Peñacoba
Good catch:
Reviewed-by: Quentin Glidic
And pushed:
ed016bff..07a2b99f master -> master
Thanks,
---
clients/desktop-shell.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/clients/desktop-shell.c b/clients/de
Signed-off-by: Raúl Peñacoba
---
clients/desktop-shell.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index 2667e9bb..599295ee 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -591,7 +591,6 @@ panel_create(struct desk
Hi,
On 15 January 2017 at 18:07, Quentin Glidic
wrote:
> On 15/01/2017 18:54, Emmanuel Gil Peyrot wrote:
>> This makes the background image look much nicer, at the expense of
>> slightly more memory bandwidth used.
>>
>> Signed-off-by: Emmanuel Gil Peyrot
>
> I see no reason not to:
> Reviewed-b
On 15/01/2017 18:54, Emmanuel Gil Peyrot wrote:
This makes the background image look much nicer, at the expense of
slightly more memory bandwidth used.
Signed-off-by: Emmanuel Gil Peyrot
I see no reason not to:
Reviewed-by: Quentin Glidic
I’ll push it as soon as someone else agree there’s n
This makes the background image look much nicer, at the expense of
slightly more memory bandwidth used.
Signed-off-by: Emmanuel Gil Peyrot
---
clients/desktop-shell.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index a1cf51df..bd0032a7 1
On 20/08/2016 18:24, Armin Krezović wrote:
On 20.08.2016 18:20, Quentin Glidic wrote:
From: Quentin Glidic
Now we properly unregister from the panel/background surface destroy
signals if the output is destroyed first.
Trivial, and it fixes a crash.
Reviewed-by: Armin Krezović
Thanks, pus
On 20.08.2016 18:20, Quentin Glidic wrote:
> From: Quentin Glidic
>
> Now we properly unregister from the panel/background surface destroy
> signals if the output is destroyed first.
Trivial, and it fixes a crash.
Reviewed-by: Armin Krezović
>
> Signed-off-by: Quentin Glidic
> ---
> deskto
From: Quentin Glidic
Now we properly unregister from the panel/background surface destroy
signals if the output is destroyed first.
Signed-off-by: Quentin Glidic
---
desktop-shell/shell.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index
On Tue, Aug 16, 2016 at 10:28:21AM +0200, Quentin Glidic wrote:
> From: Quentin Glidic
>
> Signed-off-by: Quentin Glidic
As discussed, API naming can be improved, but lets do that in the follow
up. This is
Reviewed-by: Jonas Ådahl
Jonas
> ---
> desktop-shell/shell.c | 2 +-
> 1 file chang
From: Quentin Glidic
Signed-off-by: Quentin Glidic
---
desktop-shell/shell.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 786020b..8023b0d 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2364,6 +2364,7
On Tue, May 10, 2016 at 10:18:14AM -0500, Yong Bakos wrote:
> On May 9, 2016, at 8:22 PM, Emmanuel Gil Peyrot
> wrote:
> >
> > When we receive an wl_shell_surface::set_fullscreen request for a
> > surface that was already fullscreen, don’t do anything if the
> > parameters are the same as the in
On May 9, 2016, at 8:22 PM, Emmanuel Gil Peyrot wrote:
>
> When we receive an wl_shell_surface::set_fullscreen request for a
> surface that was already fullscreen, don’t do anything if the
> parameters are the same as the initial request.
>
> This prevents bogus or malicious clients from being a
When we receive an wl_shell_surface::set_fullscreen request for a
surface that was already fullscreen, don’t do anything if the
parameters are the same as the initial request.
This prevents bogus or malicious clients from being able to always stay
on front by flooding the compositor with set_fulls
plementation.)
>
>> ---
>> clients/desktop-shell.c | 71
>> ++---
>> man/weston.ini.man | 3 +++
>> weston.ini.in | 1 +
>> 3 files changed, 66 insertions(+), 9 deletions(-)
>>
>>
3 files changed, 66 insertions(+), 9 deletions(-)
>
> diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
> index 6ab76dc..8aa7a99 100644
> --- a/clients/desktop-shell.c
> +++ b/clients/desktop-shell.c
> @@ -49,6 +49,8 @@
>
> #include "weston-desktop-shell-cli
+49,8 @@
#include "weston-desktop-shell-client-protocol.h"
+#define DEFAULT_CLOCK_FORMAT FORMAT_MINUTES
+
extern char **environ; /* defined by libc */
struct desktop {
@@ -82,6 +84,7 @@ struct panel {
struct widget *widget;
struct wl_list launcher_list;
On Mon, Nov 16, 2015 at 12:35:57PM +1000, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
Reviewed-by and pushed, thanks:
To ssh://jad...@git.freedesktop.org/git/wayland/weston
64d78bb..1118952 master -> master
Jonas
> ---
> desktop-shell/shell.c | 8 +---
> 1 file changed, 1 i
Signed-off-by: Peter Hutterer
---
desktop-shell/shell.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 52d1195..9968307 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -3303,13 +3303,7 @@ static void
On 07/10/15 01:44 AM, Jonas Ådahl wrote:
> get_shell_surface(parent) may return NULL if the client passed a
> unassigned wl_surface or a wl_surface with a non-shell surface role
> (such as cursor role).
>
> https://bugs.freedesktop.org/show_bug.cgi?id=92316
>
> Signed-off-by: Jonas Ådahl
Looks
> get_shell_surface(parent) may return NULL if the client passed a
> unassigned wl_surface or a wl_surface with a non-shell surface role
> (such as cursor role).
>
> https://bugs.freedesktop.org/show_bug.cgi?id=92316
>
> Signed-off-by: Jonas Ådahl
Tested-by: Olivier Fourdan
Works for me :-)
get_shell_surface(parent) may return NULL if the client passed a
unassigned wl_surface or a wl_surface with a non-shell surface role
(such as cursor role).
https://bugs.freedesktop.org/show_bug.cgi?id=92316
Signed-off-by: Jonas Ådahl
---
desktop-shell/shell.c | 5 +++--
1 file changed, 3 insert
On 23/09/15 02:40 PM, Derek Foreman wrote:
> Note: this email somehow confused patchwork and generated a new broken
> patch entry. I've deleted that, but replying here won't properly end up
> in the old patch's thread... sigh.
>
> On 20/09/15 12:10 PM, Manuel Bachmann wrote:
>> Hi folks,
>>
>> A
Note: this email somehow confused patchwork and generated a new broken
patch entry. I've deleted that, but replying here won't properly end up
in the old patch's thread... sigh.
On 20/09/15 12:10 PM, Manuel Bachmann wrote:
> Hi folks,
>
> Any news on this one ? (https://patchwork.freedesktop.or
Hi folks,
Any news on this one ? (https://patchwork.freedesktop.org/patch/46001/)
Just tried, the problem still shows in latest master (if you fullscreen
weston-terminal with [F11], and then minimize wih right-click ->
"Minimize", the screen stays black).
If the implementation not seeming optima
On Fri, Jun 26, 2015 at 12:37:56PM +0800, Jonas Ådahl wrote:
> In preparation for further refactoring. This patch also removes a
> redundant NULL check. Since we pass views, and views will always have an
> associated surface, there is no point of checking if it has.
>
> Signed-off-by: Jonas Ådahl
An earlier patch made surface_resize() and surface_move() take pointers
instead of seats, this updates the weston_shell_interface resize and move to
match.
Signed-off-by: Derek Foreman
---
desktop-shell/shell.c | 8
src/compositor.h | 5 +++--
xwayland/window-manager.c |
On Tue, Jul 21, 2015 at 02:31:55PM +0300, Pekka Paalanen wrote:
> On Mon, 20 Jul 2015 16:28:13 -0500
> Derek Foreman wrote:
>
> > Removing the screensaver had the accidental side effect of disabling
> > DPMS display shut down.
> >
> > Signed-off-by: Derek Foreman
> > ---
> > desktop-shell/shel
On Mon, 20 Jul 2015 16:28:13 -0500
Derek Foreman wrote:
> Removing the screensaver had the accidental side effect of disabling
> DPMS display shut down.
>
> Signed-off-by: Derek Foreman
> ---
> desktop-shell/shell.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/desktop-shell/shel
Removing the screensaver had the accidental side effect of disabling
DPMS display shut down.
Signed-off-by: Derek Foreman
---
desktop-shell/shell.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 0137ca3..9e3701f 100644
--- a/desktop-shel
Hi pekka
>Odd. You definitely should be getting first a black screen which then fades to
>the desktop once weston-desktop-shell signals ready, because you have
>startup-animation=fade.
Yes. I don't notice it before. There is a black screen flashed across before
display Weston
-cairo= option to Weston's configure?
> --With-cairo=image
Good.
> >>Does the desktop fade in from black, or does it just jump out after
> >>3 seconds?
> No black screen with Weston-desktop-shell. But if use other clients,
> there is black screen first.
>
> Th
does it just jump out after 3 seconds?
No black screen with Weston-desktop-shell. But if use other clients, there is
black screen first.
The Weston-desktop-shell start need about 1.5s. After start
Weston-desktop-shell, then start my own launcher need about 3s. I used to start
my launcher instea
st about
> > 16s. The Weston-desk-shell only cost 3s. Does there any big
> > difference between Weston-desktop-shell and other Weston client
> > examples(for example, Weston-fullscreen)?
> >
> > It is really puzzle me, could anyone can give me some hints. Thank
>
een Weston-desktop-shell and other Weston client
> examples(for example, Weston-fullscreen)?
>
> It is really puzzle me, could anyone can give me some hints. Thank
> you.
I don't know about the slowness, but you are not meant to put random
Wayland apps in place of weston-deskto
Dear all:
When I set other Weston clients in the Weston.ini instead of
Weston-deskto-shell, then start Weston is very slow. It cost about 16s. The
Weston-desk-shell only cost 3s.
Does there any big difference between Weston-desktop-shell and other Weston
client examples(for example, Weston
In preparation for further refactoring.
Signed-off-by: Jonas Ådahl
Signed-off-by: Arnaud Vrac
---
Changes since v2:
* Squashed in crash fix by Arnaud.
desktop-shell/shell.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/desktop-shell
In preparation for further refactoring. This patch also removes a
redundant NULL check. Since we pass views, and views will always have an
associated surface, there is no point of checking if it has.
Signed-off-by: Jonas Ådahl
---
Changes since v2:
* Removed redundant NULL check.
desktop-she
On Fri, 29 May 2015 09:49:52 -0500
Derek Foreman wrote:
> On 29/05/15 04:02 AM, Pekka Paalanen wrote:
> > On Tue, 26 May 2015 14:24:37 -0500
> > Derek Foreman wrote:
> >
> >> This prevents a use after free when the surfaces are automatically cleaned
> >> up later, as shell_client's entry was st
On 29/05/15 04:02 AM, Pekka Paalanen wrote:
> On Tue, 26 May 2015 14:24:37 -0500
> Derek Foreman wrote:
>
>> This prevents a use after free when the surfaces are automatically cleaned
>> up later, as shell_client's entry was still in the surface list.
>>
>> Signed-off-by: Derek Foreman
>> ---
>>
On Tue, 26 May 2015 14:24:37 -0500
Derek Foreman wrote:
> This prevents a use after free when the surfaces are automatically cleaned
> up later, as shell_client's entry was still in the surface list.
>
> Signed-off-by: Derek Foreman
> ---
>
> I'm not really well versed in this, so would apprec
On Thu, 28 May 2015 14:30:25 -0500
Derek Foreman wrote:
> On 27/05/15 02:27 AM, Pekka Paalanen wrote:
> > On Tue, 26 May 2015 23:59:41 -0700
> > Bryce Harrington wrote:
> >
> >> On Wed, May 27, 2015 at 09:48:50AM +0300, Pekka Paalanen wrote:
> >
> >>> One thing worth to note: if Weston is usin
On 27/05/15 02:27 AM, Pekka Paalanen wrote:
> On Tue, 26 May 2015 23:59:41 -0700
> Bryce Harrington wrote:
>
>> On Wed, May 27, 2015 at 09:48:50AM +0300, Pekka Paalanen wrote:
>
>>> One thing worth to note: if Weston is using "none" background meaning
>>> that we get undefined (garbage) content,
On Tue, 26 May 2015 23:59:41 -0700
Bryce Harrington wrote:
> On Wed, May 27, 2015 at 09:48:50AM +0300, Pekka Paalanen wrote:
> > One thing worth to note: if Weston is using "none" background meaning
> > that we get undefined (garbage) content, then removing a wl_surface may
> > not really remove
ote:
> > > > On 26/05/15 03:54 AM, Pekka Paalanen wrote:
> > > > > Now, when there is no black surface at all for "none", the compositor
> > > > > will show garbage until weston-desktop-shell gets everything up. This
> > > > > may be u
there is no black surface at all for "none", the compositor
> > > > will show garbage until weston-desktop-shell gets everything up. This
> > > > may be undesireable but works for tests. To have the old "none"
> > > > behaviour back, I would pro
On Tue, May 26, 2015 at 03:52:59PM +0300, Pekka Paalanen wrote:
> On Tue, 26 May 2015 07:24:04 -0500
> Derek Foreman wrote:
> > On 26/05/15 03:54 AM, Pekka Paalanen wrote:
> > > Now, when there is no black surface at all for "none", the compositor
> > >
This prevents a use after free when the surfaces are automatically cleaned
up later, as shell_client's entry was still in the surface list.
Signed-off-by: Derek Foreman
---
I'm not really well versed in this, so would appreciate extra critical
review here, as this trivial patch may be trivially
face when the startup animation is
>>> specified to be "none". This is the final fix needed to make the
>>> screenshot test deterministic and independent of weston-desktop-shell.
>>>
>>> Previously, the black surface would cover all outputs until
>>
eeded to make the
> > screenshot test deterministic and independent of weston-desktop-shell.
> >
> > Previously, the black surface would cover all outputs until
> > weston-desktop-shell signalled ready. Then, depending on the set
> > animation, either the black su
On 26/05/15 03:54 AM, Pekka Paalanen wrote:
> From: Pekka Paalanen
>
> Do not use a black blanket surface when the startup animation is
> specified to be "none". This is the final fix needed to make the
> screenshot test deterministic and independent of weston-desktop-sh
On Tue, 14 Apr 2015 17:09:06 -0500
Derek Foreman wrote:
> It's possible for more than one animation to be taking place on a view at
> the same time. If one of those animations is the shell's fade out for
> dying surfaces, its completion handler will trigger the surface destroy
> signal, causing
;. This is the final fix needed to make the
> > screenshot test deterministic and independent of weston-desktop-shell.
> >
> > Previously, the black surface would cover all outputs until
> > weston-desktop-shell signalled ready. Then, depending on the set
> > animation,
On Tue, 26 May 2015 11:54:52 +0300
Pekka Paalanen wrote:
> From: Pekka Paalanen
>
> Do not use a black blanket surface when the startup animation is
> specified to be "none". This is the final fix needed to make the
> screenshot test deterministic and independen
From: Pekka Paalanen
Do not use a black blanket surface when the startup animation is
specified to be "none". This is the final fix needed to make the
screenshot test deterministic and independent of weston-desktop-shell.
Previously, the black surface would cover all outputs un
On Sat, May 02, 2015 at 09:44:04PM +0900, Ryo Munakata wrote:
> Weston has sent the first 'resizing' configure event with width=height=0.
> But resizing to that size doesn't make sense.
> Instead, we now send the current width and height of the surface at the
> beginning
> of resizing.
>
> Signed
Weston has sent the first 'resizing' configure event with width=height=0.
But resizing to that size doesn't make sense.
Instead, we now send the current width and height of the surface at the
beginning
of resizing.
Signed-off-by: Ryo Munakata
---
desktop-shell/shell.c | 3 +++
1 file changed, 3
It's possible for more than one animation to be taking place on a view at
the same time. If one of those animations is the shell's fade out for
dying surfaces, its completion handler will trigger the surface destroy
signal, causing other animations on the animation list to remove themselves.
Sinc
On Mon, 13 Apr 2015 22:47:00 -0500
Derek Foreman wrote:
> On 13/04/15 07:15 AM, Pekka Paalanen wrote:
> > On Fri, 10 Apr 2015 12:54:46 -0500
> > Derek Foreman wrote:
> >
> >> The completion of the fade out animation destroys a surface which fires
> >> the surface destroy signal. Animations lis
On 13/04/15 07:15 AM, Pekka Paalanen wrote:
> On Fri, 10 Apr 2015 12:54:46 -0500
> Derek Foreman wrote:
>
>> The completion of the fade out animation destroys a surface which fires
>> the surface destroy signal. Animations listen for the surface destroy
>> signal and destroy themselves as a resp
On Fri, 10 Apr 2015 12:54:46 -0500
Derek Foreman wrote:
> The completion of the fade out animation destroys a surface which fires
> the surface destroy signal. Animations listen for the surface destroy
> signal and destroy themselves as a response.
>
> If there's an animation running on a surfa
Sure, I'll remove it then. (I was going to remove it originally - but
figured, it was useful for testing since it exposed this bug.)
On Wed, Apr 8, 2015 at 7:00 AM, Pekka Paalanen wrote:
> On Mon, 6 Apr 2015 13:27:23 -0700
> Dima Ryazanov wrote:
>
> > Yeah, the logic is pretty sketchy now - "if
On Mon, 6 Apr 2015 13:27:23 -0700
Dima Ryazanov wrote:
> Yeah, the logic is pretty sketchy now - "if it's a shell surface, do the
> error checking; otherwise, do nothing" - but I don't understand the code
> well enough to know if this is the expected behavior.
>
> Should the panel just be a shel
Yeah, the logic is pretty sketchy now - "if it's a shell surface, do the
error checking; otherwise, do nothing" - but I don't understand the code
well enough to know if this is the expected behavior.
Should the panel just be a shell surface? Then we could require that the
popup's parent is a shell
This bug was introduced in commits da6ecd0cc52 and 24185e2561
I guess nobody right clicked on the panel for over a month. :)
I've CC'd Jasper and Jonas in case they haven't noticed this yet...
On 06/04/15 01:52 AM, Dima Ryazanov wrote:
> It looks like the error-checking code assumes the popup's
It looks like the error-checking code assumes the popup's parent is
a shell surface - but that's not always the case.
Signed-off-by: Dima Ryazanov
---
desktop-shell/shell.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
From: Manuel Bachmann
If a fullscreen surface was minimized, the shell would keep
its fullscreen mode activated, and only a black background
would be visible.
Signed-off-by: Manuel Bachmann
---
desktop-shell/shell.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff -
On Wed, Mar 18, 2015 at 10:21:59AM -0700, Jasper St. Pierre wrote:
> Yeah, this is obviously correct.
>
> Reviewed-by: Jasper St. Pierre
Thanks, applied:
561662b..70ac0ed master -> master
> On Wed, Mar 18, 2015 at 9:16 AM, Derek Foreman
> wrote:
>
> > Now clamping width and height to a
Yeah, this is obviously correct.
Reviewed-by: Jasper St. Pierre
On Wed, Mar 18, 2015 at 9:16 AM, Derek Foreman
wrote:
> Now clamping width and height to a minimum of 1, 1 when drag resizing.
>
> Signed-off-by: Derek Foreman
> ---
> desktop-shell/shell.c | 4
> 1 file changed, 4 insertio
Now clamping width and height to a minimum of 1, 1 when drag resizing.
Signed-off-by: Derek Foreman
---
desktop-shell/shell.c | 4
1 file changed, 4 insertions(+)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 826692f..aca91eb 100644
--- a/desktop-shell/shell.c
+++ b/desk
On Thu, Feb 5, 2015 at 5:11 AM, Daniel Stone wrote:
> Hi,
>
> On 5 February 2015 at 08:58, Jonas Ådahl wrote:
> > If a client calls xdg_shell.get_xdg_surface on a surface that is already
> > an xdg_surface wold, prior to this patch, succeed, but cause weston to
> > crash later when trying to con
On Thu, Feb 05, 2015 at 04:58:05PM +0800, Jonas Ådahl wrote:
> If a client calls xdg_shell.get_xdg_surface on a surface that is already
> an xdg_surface wold, prior to this patch, succeed, but cause weston to
s/wold/would/
> crash later when trying to configure. This patch instead sends a role
>
On Thu, Feb 05, 2015 at 01:11:54PM +, Daniel Stone wrote:
> Hi,
>
> On 5 February 2015 at 08:58, Jonas Ådahl wrote:
> > If a client calls xdg_shell.get_xdg_surface on a surface that is already
> > an xdg_surface wold, prior to this patch, succeed, but cause weston to
> > crash later when tryi
Hi,
On 5 February 2015 at 08:58, Jonas Ådahl wrote:
> If a client calls xdg_shell.get_xdg_surface on a surface that is already
> an xdg_surface wold, prior to this patch, succeed, but cause weston to
> crash later when trying to configure. This patch instead sends a role
> error to the client com
If a client calls xdg_shell.get_xdg_surface on a surface that is already
an xdg_surface wold, prior to this patch, succeed, but cause weston to
crash later when trying to configure. This patch instead sends a role
error to the client complaining that it already is an xdg_surface.
Note that .._set_
On Fri, Jan 30, 2015 at 11:30:42AM -0800, Jon A. Cruz wrote:
> Looks good.
>
> Reviewed-by: Jon A. Cruz
Thanks, applied:
aff7c33..8aeeac8 master -> master
> On 01/30/2015 11:24 AM, Derek Foreman wrote:
> > Remove a few instances of casting weston_seat to weston_seat.
> >
> > Signed-off-b
On Wed, Jan 07, 2015 at 08:04:05AM +1000, Peter Hutterer wrote:
> On Tue, Jan 06, 2015 at 02:28:13PM -0600, Derek Foreman wrote:
> > The zoom effect zooms at the seat's current pointer location. When no
> > pointer is present the zoom key bindings cause a crash.
> >
> > Instead, check for the abs
Looks good.
Reviewed-by: Jon A. Cruz
On 01/30/2015 11:24 AM, Derek Foreman wrote:
> Remove a few instances of casting weston_seat to weston_seat.
>
> Signed-off-by: Derek Foreman
> ---
> desktop-shell/shell.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --
Remove a few instances of casting weston_seat to weston_seat.
Signed-off-by: Derek Foreman
---
desktop-shell/shell.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index f6d9c79..0793352 100644
--- a/desktop-shell
On 06/01/15 09:27 PM, Jonas Ådahl wrote:
> On Tue, Jan 06, 2015 at 02:28:13PM -0600, Derek Foreman wrote:
>> The zoom effect zooms at the seat's current pointer location. When no
>> pointer is present the zoom key bindings cause a crash.
>>
>> Instead, check for the absence of a pointer and log a
On Tue, Jan 06, 2015 at 07:49:50PM -0600, Derek Foreman wrote:
> On 06/01/15 04:04 PM, Peter Hutterer wrote:
> > On Tue, Jan 06, 2015 at 02:28:13PM -0600, Derek Foreman wrote:
> >> The zoom effect zooms at the seat's current pointer location. When no
> >> pointer is present the zoom key bindings c
On Tue, Jan 06, 2015 at 02:28:13PM -0600, Derek Foreman wrote:
> The zoom effect zooms at the seat's current pointer location. When no
> pointer is present the zoom key bindings cause a crash.
>
> Instead, check for the absence of a pointer and log a warning.
>
> Signed-off-by: Derek Foreman
>
On 06/01/15 04:04 PM, Peter Hutterer wrote:
> On Tue, Jan 06, 2015 at 02:28:13PM -0600, Derek Foreman wrote:
>> The zoom effect zooms at the seat's current pointer location. When no
>> pointer is present the zoom key bindings cause a crash.
>>
>> Instead, check for the absence of a pointer and log
1 - 100 of 149 matches
Mail list logo
