Re: absolute positioning and other "missing features" of Wayland

[Dima Ryazanov]

Thanks everyone! This was quite a bit of interesting feedback.

Let me add Alexandros to this thread, too, in case he has any input - if
the existing hacks seem to be sufficient, or if it makes sense to create a
new protocol.

(Alexandros: I'm by no means an expert here, but saw your work on Wine, and
thought it would be useful to start a discussion. If you're not already on
the mailing list, see the full thread here:
https://lists.freedesktop.org/archives/wayland-devel/2021-February/041718.html
)

On Mon, Feb 22, 2021 at 9:23 AM Carsten Haitzler 
wrote:

> On Mon, 22 Feb 2021 12:10:08 +0100 Jonas Ådahl  said:
>
> > On Mon, Feb 22, 2021 at 10:49:33AM +, Simon Ser wrote:
> > > On Monday, February 22nd, 2021 at 11:44 AM, Carsten Haitzler
> > >  wrote:
> > >
> > > > I also would want to avoid baking explicit absolute positioning into
> > > > wayland protocol - be it as a core agreed to add-on to xdg-shell or
> even
> > > > a "commonly supported extension". What I'd like it some better
> solution.
> > > > For example - if an app wants to absolute position a window because
> it's
> > > > doing a custom "my own notification popup" much like Chrome and
> Firefox
> > > > now like to do in X11, then I'd prefer this be explicitly exposed as
> a
> > > > "notification surface with requested screen location hints" and so
> the
> > > > compositor can decide to do something more intelligent with it. I am
> sure
> > > > this list of use cases will probably be extensive and also depend on
> the
> > > > API in wine that is being wrapped and intercepted - the higher level
> it
> > > > is, the more it knows about the intended use case.
> > >
> > > I'd like to avoid making this general, if we go down this road. Make it
> > > specific to the win32 API and wine. Wayland-native toolkits don't need
> > > it.
> >
> > Sounds potentially not horrible in theory, but is it remotely possible?
> > There are these approaches I can think of:
>
> It's still open to abuse eventually for the wrong reasons no matter where
> it
> is.
>
> >  * Add a "wl_win32" to wayland-protocols
> >
> > Adoption by anyone wanting to bypass the Wayland windowing model can use
> > it trivially, and we have a X11 like situation where everything grabs
> > everything and arbitrary client driven window self management.
> >
> >  * Make "wine" distribute a "wl_win32.xml" and make compositors depend on
> >on wine-devel, implementing the protocol.
> >
> > Practically the same as above, just a 'cp ~/wine/protocols/wl-win32
> > protocols' away, and we're back with wierd grabs and client managing
> > their own surfaces again.
> >
> >  * A libwine-wayland, a wineBindWaylandDisplay() with some kind of half
> >assed authentication.
> >
> > I assume noone wants this (including me). But client developers would
> > have to be really obnoxious to work around it which might be enough to
> > not make it general.
> >
> > A "allow/deny" nag/query (aka "Do you want this application you
> > installed to work or want me to break it for you?") I wouldn't call a
> > reasonable option either.
>
> I think the nag is probably the way to go. Or specifically the compositor
> should ask once and remember the response (or have an option to never ask
> and
> always allow this if users so desire).
>
> > So, how would we make it not de-facto general?
> >
> > Not to meantion the head ache of letting clients in on configuring their
> > window positions when any kind of HiDPI scaling, fractional or nat, is
> > done.
>
> Indeed this is the problem as well as odd displays like circular ones as
> well.
> It opens the doors to clients making assumptions that may not be true given
> various methods a compositor might use to handle multiple screens with
> differing DPI/scaling etc.
>
> > >
> > > Notifications popups are part of the desktop environment and clients
> > > shouldn't try to display them directly.
>
> But they do. Give them an inch and they take a mile. :)
>
> > Agreed.
> >
> >
> > Jonas
> >
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> Carsten Haitzler - ras...@rasterman.com
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

absolute positioning and other "missing features" of Wayland

[Dima Ryazanov]

Hi everyone,

I realize this has always been a controversial topic; I apologize for
bringing it up yet again, but I'm wondering if there could be some
compromise here.

I've been following the development of the Wayland driver for Wine [1] -
and it's one of the examples where "applications shouldn't know or care
about window positioning" doesn't really make sense. Wine is a
compatibility layer; it's not up to Wine what the application is trying to
do. Right now, properly supporting Wine on Wayland is (almost) impossible -
and Wine developers' stance seems to be "We'll stay with X11 because
Wayland is incomplete" [2].

Most Wayland compositors support XWayland, and therefore, are ok with
applications using absolute positioning - as long as the application is
using the X11 protocol. Would a Wayland protocol extension for this be a
"lesser evil"? It could allow specific applications like Wine to access the
"undesirable" features, while other applications would be restricted to the
main protocols.

Of course, nothing stops Gnome or any other compositor from implementing
its own protocol for this - but I was hoping to hear some feedback and
opinions, and possibly come up with a solution that everyone is happy with.

[1]
https://www.collabora.com/news-and-blog/news-and-events/wayland-on-wine-an-exciting-first-update.html
[2] https://www.winehq.org/pipermail/wine-devel/2021-February/181338.html
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: After display protocol error communication between wayland protocol and client is broken.

[Dima Ryazanov]

Hello,

Yes, that's expected. From the documentation
:
"The error event is sent out when a fatal (non-recoverable) error has
occurred"
It indicates a bug in the code, so there's no point in handling the error.

On Thu, Dec 27, 2018 at 6:40 AM Ikshwaku Chauhan 
wrote:

> Hello All,
>
> We are facing an issue where we are not receiving any surface/layer
> creation/distortion notifications from Layermanager.
>
> We debugged and found that, once we get "*display protocol error :
> Invalid Object XX" i.e, (wl_display@1.error(wl_display@1, 0, "invalid
> object XX"))* on wayland client side, there is No further communication
> between Wayland Protocol and Client to and from both.
>
> Is this an expected behavior or any recovery is possible?
>
> We are using wayland/weston/wayland-ivi-extension 1.11.0 with drm-backend
> on TI's Soc.
>
> Thanks you in advance.
>
>
> Regards,
>
> Ikshwaku
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Don't look for weston.ini in the current working directory

[Dima Ryazanov]

Done! I somehow missed the move to Gitlab.

On Thu, Nov 15, 2018 at 12:14 AM Pekka Paalanen  wrote:

> On Wed, 14 Nov 2018 23:02:12 -0800
> Dima Ryazanov  wrote:
>
> > It's a bit surprising that Weston looks different when launched from the
> root
> > of the git repo vs from elsewhere.
> >
> > But it's also technically a security vulnerability: if I launch it from
> > a directory like /tmp, it might pick up a weston.ini created by another
> user,
> > which could then load modules with arbitrary code. Basically, it's the
> same
> > problem as including "." in $PATH.
> >
> > Signed-off-by: Dima Ryazanov 
>
> Hi Dima,
>
> I agree with this change:
>
> Acked-by: Pekka Paalanen 
>
>
> Weston patch submission has moved into Gitlab merge requests though.
> Could you re-send as Gitlab MRs, please?
>
> The contribution guide should have everything you need to know. Don't
> forget to update Patchwork status if you re-send in Gitlab.
>
> The mailing list submissions and patches still open in Patchwork are
> not intended to be discarded, but it seems most people have moved
> completely to Gitlab review process, so picking up Weston patches from
> Patchwork has been even slower than before.
>
>
> Thanks,
> pq
>
> > ---
> >  man/weston.ini.man | 1 -
> >  man/weston.man | 4 +---
> >  shared/config-parser.c | 8 ++--
> >  3 files changed, 3 insertions(+), 10 deletions(-)
> >
> > diff --git a/man/weston.ini.man b/man/weston.ini.man
> > index c12e0505..2171b960 100644
> > --- a/man/weston.ini.man
> > +++ b/man/weston.ini.man
> > @@ -27,7 +27,6 @@ server is started:
> >  .B  "weston/weston.ini in each"
> >  .BR "\ \ \ \ $XDG_CONFIG_DIR   " "(if $XDG_CONFIG_DIRS is set)"
> >  .BR "/etc/xdg/weston/weston.ini" "(if $XDG_CONFIG_DIRS is not set)"
> > -.BR "/weston.ini  " "(if no variables were set)"
> >  .fi
> >  .RE
> >  .PP
> > diff --git a/man/weston.man b/man/weston.man
> > index c09d4c2d..c1aa6476 100644
> > --- a/man/weston.man
> > +++ b/man/weston.man
> > @@ -261,14 +261,12 @@ See
> >  .SH FILES
> >  .
> >  If the environment variable is set, the configuration file is read
> > -from the respective path, or the current directory if neither is set.
> > +from the respective path.
> >  .PP
> >  .BI $XDG_CONFIG_HOME /weston.ini
> >  .br
> >  .BI $HOME /.config/weston.ini
> >  .br
> > -.I ./weston.ini
> > -.br
> >  .
> >  .\" ***
> >  .SH ENVIRONMENT
> > diff --git a/shared/config-parser.c b/shared/config-parser.c
> > index ae5f8035..7b1402d2 100644
> > --- a/shared/config-parser.c
> > +++ b/shared/config-parser.c
> > @@ -75,8 +75,7 @@ open_config_file(struct weston_config *c, const char
> *name)
> >   }
> >
> >   /* Precedence is given to config files in the home directory,
> > -  * and then to directories listed in XDG_CONFIG_DIRS and
> > -  * finally to the current working directory. */
> > +  * then to directories listed in XDG_CONFIG_DIRS. */
> >
> >   /* $XDG_CONFIG_HOME */
> >   if (config_dir) {
> > @@ -111,10 +110,7 @@ open_config_file(struct weston_config *c, const
> char *name)
> >   next++;
> >   }
> >
> > - /* Current working directory. */
> > - snprintf(c->path, sizeof c->path, "./%s", name);
> > -
> > - return open(c->path, O_RDONLY | O_CLOEXEC);
> > + return -1;
> >  }
> >
> >  static struct weston_config_entry *
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Don't look for weston.ini in the current working directory

[Dima Ryazanov]

It's a bit surprising that Weston looks different when launched from the root
of the git repo vs from elsewhere.

But it's also technically a security vulnerability: if I launch it from
a directory like /tmp, it might pick up a weston.ini created by another user,
which could then load modules with arbitrary code. Basically, it's the same
problem as including "." in $PATH.

Signed-off-by: Dima Ryazanov 
---
 man/weston.ini.man | 1 -
 man/weston.man | 4 +---
 shared/config-parser.c | 8 ++--
 3 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/man/weston.ini.man b/man/weston.ini.man
index c12e0505..2171b960 100644
--- a/man/weston.ini.man
+++ b/man/weston.ini.man
@@ -27,7 +27,6 @@ server is started:
 .B  "weston/weston.ini in each"
 .BR "\ \ \ \ $XDG_CONFIG_DIR   " "(if $XDG_CONFIG_DIRS is set)"
 .BR "/etc/xdg/weston/weston.ini" "(if $XDG_CONFIG_DIRS is not set)"
-.BR "/weston.ini  " "(if no variables were set)"
 .fi
 .RE
 .PP
diff --git a/man/weston.man b/man/weston.man
index c09d4c2d..c1aa6476 100644
--- a/man/weston.man
+++ b/man/weston.man
@@ -261,14 +261,12 @@ See
 .SH FILES
 .
 If the environment variable is set, the configuration file is read
-from the respective path, or the current directory if neither is set.
+from the respective path.
 .PP
 .BI $XDG_CONFIG_HOME /weston.ini
 .br
 .BI $HOME /.config/weston.ini
 .br
-.I ./weston.ini
-.br
 .
 .\" ***
 .SH ENVIRONMENT
diff --git a/shared/config-parser.c b/shared/config-parser.c
index ae5f8035..7b1402d2 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -75,8 +75,7 @@ open_config_file(struct weston_config *c, const char *name)
}
 
/* Precedence is given to config files in the home directory,
-* and then to directories listed in XDG_CONFIG_DIRS and
-* finally to the current working directory. */
+* then to directories listed in XDG_CONFIG_DIRS. */
 
/* $XDG_CONFIG_HOME */
if (config_dir) {
@@ -111,10 +110,7 @@ open_config_file(struct weston_config *c, const char *name)
next++;
}
 
-   /* Current working directory. */
-   snprintf(c->path, sizeof c->path, "./%s", name);
-
-   return open(c->path, O_RDONLY | O_CLOEXEC);
+   return -1;
 }
 
 static struct weston_config_entry *
-- 
2.19.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 2/3] Delete an unused variable

[Dima Ryazanov]

Signed-off-by: Dima Ryazanov 
---
 clients/window.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index 1ab33545..470ac090 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -278,7 +278,6 @@ struct window {
 
struct zwp_relative_pointer_v1 *relative_pointer;
struct zwp_locked_pointer_v1 *locked_pointer;
-   struct input *locked_input;
bool pointer_locked;
locked_pointer_locked_handler_t pointer_locked_handler;
locked_pointer_unlocked_handler_t pointer_unlocked_handler;
@@ -4866,7 +4865,6 @@ window_lock_pointer(struct window *window, struct input 
*input)
   _pointer_listener,
   input);
 
-   window->locked_input = input;
window->locked_pointer = locked_pointer;
window->relative_pointer = relative_pointer;
 
@@ -4884,7 +4882,6 @@ window_unlock_pointer(struct window *window)
window->locked_pointer = NULL;
window->relative_pointer = NULL;
window->pointer_locked = false;
-   window->locked_input = NULL;
 }
 
 void
-- 
2.19.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 3/3] A better fix for a crash when unlocking or unconfining a pointer

[Dima Ryazanov]

This is a rewrite of the fix in:
https://lists.freedesktop.org/archives/wayland-devel/2018-May/038140.html

It addresses Pekka's concerns about window getting destroyed before the
unlock/unconfine event is triggered.

Signed-off-by: Dima Ryazanov 
---
 clients/window.c | 31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index 470ac090..d55d27eb 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -343,6 +343,8 @@ struct input {
struct window *pointer_focus;
struct window *keyboard_focus;
struct window *touch_focus;
+   struct window *locked_window;
+   struct window *confined_window;
int current_cursor;
uint32_t cursor_anim_start;
struct wl_callback *cursor_frame_cb;
@@ -1584,6 +1586,10 @@ window_destroy(struct window *window)
input->pointer_focus = NULL;
if (input->keyboard_focus == window)
input->keyboard_focus = NULL;
+   if (input->locked_window == window)
+   input->locked_window = NULL;
+   if (input->confined_window == window)
+   input->confined_window = NULL;
if (input->focus_widget &&
input->focus_widget->window == window)
input->focus_widget = NULL;
@@ -4792,7 +4798,10 @@ locked_pointer_locked(void *data,
  struct zwp_locked_pointer_v1 *locked_pointer)
 {
struct input *input = data;
-   struct window *window = input->pointer_focus;
+   struct window *window = input->locked_window;
+
+   if (!window)
+   return;
 
window->pointer_locked = true;
 
@@ -4808,10 +4817,15 @@ locked_pointer_unlocked(void *data,
struct zwp_locked_pointer_v1 *locked_pointer)
 {
struct input *input = data;
-   struct window *window = input->pointer_focus;
+   struct window *window = input->locked_window;
+
+   if (!window)
+   return;
 
window_unlock_pointer(window);
 
+   input->locked_window = NULL;
+
if (window->pointer_unlocked_handler) {
window->pointer_unlocked_handler(window,
 input,
@@ -4867,6 +4881,7 @@ window_lock_pointer(struct window *window, struct input 
*input)
 
window->locked_pointer = locked_pointer;
window->relative_pointer = relative_pointer;
+   input->locked_window = window;
 
return 0;
 }
@@ -4904,7 +4919,10 @@ confined_pointer_confined(void *data,
  struct zwp_confined_pointer_v1 *confined_pointer)
 {
struct input *input = data;
-   struct window *window = input->pointer_focus;
+   struct window *window = input->confined_window;
+
+   if (!window)
+   return;
 
window->confined = true;
 
@@ -4920,11 +4938,15 @@ confined_pointer_unconfined(void *data,
struct zwp_confined_pointer_v1 *confined_pointer)
 {
struct input *input = data;
-   struct window *window = input->pointer_focus;
+   struct window *window = input->confined_window;
+
+   if (!window)
+   return;
 
window_unconfine_pointer(window);
 
window->confined = false;
+   input->confined_window = NULL;
 
if (window->pointer_unconfined_handler) {
window->pointer_unconfined_handler(window,
@@ -4989,6 +5011,7 @@ window_confine_pointer_to_rectangles(struct window 
*window,
 
window->confined_pointer = confined_pointer;
window->confined_widget = NULL;
+   input->confined_window = window;
 
return 0;
 }
-- 
2.19.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 1/3] Revert "Fix a crash when unlocking or unconfining a pointer"

[Dima Ryazanov]

This reverts commit e0dc5d47cb5f29deec495efd958fcd5f6f833389.

Signed-off-by: Dima Ryazanov 
---
 clients/window.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index 12939cb7..1ab33545 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -286,7 +286,6 @@ struct window {
confined_pointer_unconfined_handler_t pointer_unconfined_handler;
 
struct zwp_confined_pointer_v1 *confined_pointer;
-   struct input *confined_input;
struct widget *confined_widget;
bool confined;
 
@@ -4793,8 +4792,8 @@ static void
 locked_pointer_locked(void *data,
  struct zwp_locked_pointer_v1 *locked_pointer)
 {
-   struct window *window = data;
-   struct input *input = window->locked_input;
+   struct input *input = data;
+   struct window *window = input->pointer_focus;
 
window->pointer_locked = true;
 
@@ -4809,8 +4808,8 @@ static void
 locked_pointer_unlocked(void *data,
struct zwp_locked_pointer_v1 *locked_pointer)
 {
-   struct window *window = data;
-   struct input *input = window->locked_input;
+   struct input *input = data;
+   struct window *window = input->pointer_focus;
 
window_unlock_pointer(window);
 
@@ -4865,7 +4864,7 @@ window_lock_pointer(struct window *window, struct input 
*input)

ZWP_POINTER_CONSTRAINTS_V1_LIFETIME_ONESHOT);
zwp_locked_pointer_v1_add_listener(locked_pointer,
   _pointer_listener,
-  window);
+  input);
 
window->locked_input = input;
window->locked_pointer = locked_pointer;
@@ -4907,8 +4906,8 @@ static void
 confined_pointer_confined(void *data,
  struct zwp_confined_pointer_v1 *confined_pointer)
 {
-   struct window *window = data;
-   struct input *input = window->confined_input;
+   struct input *input = data;
+   struct window *window = input->pointer_focus;
 
window->confined = true;
 
@@ -4923,8 +4922,8 @@ static void
 confined_pointer_unconfined(void *data,
struct zwp_confined_pointer_v1 *confined_pointer)
 {
-   struct window *window = data;
-   struct input *input = window->confined_input;
+   struct input *input = data;
+   struct window *window = input->pointer_focus;
 
window_unconfine_pointer(window);
 
@@ -4989,9 +4988,8 @@ window_confine_pointer_to_rectangles(struct window 
*window,
 
zwp_confined_pointer_v1_add_listener(confined_pointer,
 _pointer_listener,
-window);
+input);
 
-   window->confined_input = input;
window->confined_pointer = confined_pointer;
window->confined_widget = NULL;
 
@@ -5052,7 +5050,6 @@ window_unconfine_pointer(struct window *window)
zwp_confined_pointer_v1_destroy(window->confined_pointer);
window->confined_pointer = NULL;
window->confined = false;
-   window->confined_input = NULL;
 }
 
 static void
-- 
2.19.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] Fix a crash when unlocking or unconfining a pointer

[Dima Ryazanov]

On Tue, May 29, 2018 at 3:30 AM Pekka Paalanen  wrote:

> On Thu, 10 May 2018 00:53:38 -0700
> Dima Ryazanov  wrote:
>
> > In GNOME (but not in Weston), if a window loses focus, the client first
> receives
> > the focus event, then the unlock/unconfine event. This causes toytoolkit
> to
> > dereference a NULL window when unlocking or unconfining the pointer.
> >
> > To repro:
> > - Run weston-confine
> > - Click the window
> > - Alt-Tab away from it
> >
> > Result:
> >
> > [1606837.869] wl_keyboard@19.modifiers(63944, 524352, 0, 0, 0)
> > [1606837.926] wl_keyboard@19.leave(63945, wl_surface@15)
> > [1606837.945] wl_pointer@18.leave(63946, wl_surface@15)
> > [1606837.956] wl_pointer@18.frame()
> > [1606837.961] zwp_confined_pointer_v1@26.unconfined()
> > Segmentation fault (core dumped)
> >
> > To fix this, get the input from the window instead of the other way
> around.
> >
> > Signed-off-by: Dima Ryazanov 
> > ---
> >  clients/window.c | 23 +--
> >  1 file changed, 13 insertions(+), 10 deletions(-)
> >
>
> Hi Dima,
>
> thank you for the patch, and sorry, I know you have some very old
> patches still waiting for reviews.
>

Haha, no worries!


> > diff --git a/clients/window.c b/clients/window.c
> > index bcf2b017..dee4455f 100644
> > --- a/clients/window.c
> > +++ b/clients/window.c
> > @@ -286,6 +286,7 @@ struct window {
> >   confined_pointer_unconfined_handler_t pointer_unconfined_handler;
> >
> >   struct zwp_confined_pointer_v1 *confined_pointer;
> > + struct input *confined_input;
> >   struct widget *confined_widget;
> >   bool confined;
> >
> > @@ -4788,8 +4789,8 @@ static void
> >  locked_pointer_locked(void *data,
> > struct zwp_locked_pointer_v1 *locked_pointer)
> >  {
> > - struct input *input = data;
> > - struct window *window = input->pointer_focus;
> > + struct window *window = data;
> > + struct input *input = window->locked_input;
> >
> >   window->pointer_locked = true;
> >
> > @@ -4804,8 +4805,8 @@ static void
> >  locked_pointer_unlocked(void *data,
> >   struct zwp_locked_pointer_v1 *locked_pointer)
> >  {
> > - struct input *input = data;
> > - struct window *window = input->pointer_focus;
> > + struct window *window = data;
> > + struct input *input = window->locked_input;
> >
> >   window_unlock_pointer(window);
> >
> > @@ -4860,7 +4861,7 @@ window_lock_pointer(struct window *window, struct
> input *input)
> >
>  ZWP_POINTER_CONSTRAINTS_V1_LIFETIME_ONESHOT);
> >   zwp_locked_pointer_v1_add_listener(locked_pointer,
> >  _pointer_listener,
> > -input);
> > +window);
>
> Now that this object will have a pointer to window, how do we safeguard
> against window_destroy() getting called before we dispatch a locked or
> unlocked event? Wouldn't that be necessary?
>

Ah, interesting, I did not think about that. I'll see if I can make it
happen. I'm guessing window_destroy should call window_unconfine_pointer and
window_unlock_pointer.

>
> >   window->locked_input = input;
> >   window->locked_pointer = locked_pointer;
> > @@ -4902,8 +4903,8 @@ static void
> >  confined_pointer_confined(void *data,
> > struct zwp_confined_pointer_v1 *confined_pointer)
> >  {
> > - struct input *input = data;
> > - struct window *window = input->pointer_focus;
> > + struct window *window = data;
> > + struct input *input = window->confined_input;
> >
> >   window->confined = true;
> >
> > @@ -4918,8 +4919,8 @@ static void
> >  confined_pointer_unconfined(void *data,
> >   struct zwp_confined_pointer_v1
> *confined_pointer)
> >  {
> > - struct input *input = data;
> > - struct window *window = input->pointer_focus;
> > + struct window *window = data;
> > + struct input *input = window->confined_input;
> >
> >   window_unconfine_pointer(window);
> >
> > @@ -4984,8 +4985,9 @@ window_confine_pointer_to_rectangles(struct window
> *window,
> >
> >   zwp_confined_pointer_v1_add_listener(confined_pointer,
> >_pointer_listener,
> > -  inpu

[PATCH weston] Fix a crash when unlocking or unconfining a pointer

[Dima Ryazanov]

In GNOME (but not in Weston), if a window loses focus, the client first receives
the focus event, then the unlock/unconfine event. This causes toytoolkit to
dereference a NULL window when unlocking or unconfining the pointer.

To repro:
- Run weston-confine
- Click the window
- Alt-Tab away from it

Result:

[1606837.869] wl_keyboard@19.modifiers(63944, 524352, 0, 0, 0)
[1606837.926] wl_keyboard@19.leave(63945, wl_surface@15)
[1606837.945] wl_pointer@18.leave(63946, wl_surface@15)
[1606837.956] wl_pointer@18.frame()
[1606837.961] zwp_confined_pointer_v1@26.unconfined()
Segmentation fault (core dumped)

To fix this, get the input from the window instead of the other way around.

Signed-off-by: Dima Ryazanov <d...@gmail.com>
---
 clients/window.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index bcf2b017..dee4455f 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -286,6 +286,7 @@ struct window {
confined_pointer_unconfined_handler_t pointer_unconfined_handler;
 
struct zwp_confined_pointer_v1 *confined_pointer;
+   struct input *confined_input;
struct widget *confined_widget;
bool confined;
 
@@ -4788,8 +4789,8 @@ static void
 locked_pointer_locked(void *data,
  struct zwp_locked_pointer_v1 *locked_pointer)
 {
-   struct input *input = data;
-   struct window *window = input->pointer_focus;
+   struct window *window = data;
+   struct input *input = window->locked_input;
 
window->pointer_locked = true;
 
@@ -4804,8 +4805,8 @@ static void
 locked_pointer_unlocked(void *data,
struct zwp_locked_pointer_v1 *locked_pointer)
 {
-   struct input *input = data;
-   struct window *window = input->pointer_focus;
+   struct window *window = data;
+   struct input *input = window->locked_input;
 
window_unlock_pointer(window);
 
@@ -4860,7 +4861,7 @@ window_lock_pointer(struct window *window, struct input 
*input)

ZWP_POINTER_CONSTRAINTS_V1_LIFETIME_ONESHOT);
zwp_locked_pointer_v1_add_listener(locked_pointer,
   _pointer_listener,
-  input);
+  window);
 
window->locked_input = input;
window->locked_pointer = locked_pointer;
@@ -4902,8 +4903,8 @@ static void
 confined_pointer_confined(void *data,
  struct zwp_confined_pointer_v1 *confined_pointer)
 {
-   struct input *input = data;
-   struct window *window = input->pointer_focus;
+   struct window *window = data;
+   struct input *input = window->confined_input;
 
window->confined = true;
 
@@ -4918,8 +4919,8 @@ static void
 confined_pointer_unconfined(void *data,
struct zwp_confined_pointer_v1 *confined_pointer)
 {
-   struct input *input = data;
-   struct window *window = input->pointer_focus;
+   struct window *window = data;
+   struct input *input = window->confined_input;
 
window_unconfine_pointer(window);
 
@@ -4984,8 +4985,9 @@ window_confine_pointer_to_rectangles(struct window 
*window,
 
zwp_confined_pointer_v1_add_listener(confined_pointer,
 _pointer_listener,
-input);
+window);
 
+   window->confined_input = input;
window->confined_pointer = confined_pointer;
window->confined_widget = NULL;
 
@@ -5046,6 +5048,7 @@ window_unconfine_pointer(struct window *window)
zwp_confined_pointer_v1_destroy(window->confined_pointer);
window->confined_pointer = NULL;
window->confined = false;
+   window->confined_input = NULL;
 }
 
 static void
-- 
2.17.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] Fix an uninitialized variable

[Dima Ryazanov]

"has_discrete" gets set to true in if/else if, but gets left unset otherwise.
So let's initialize it to false.

(This was caught by valgrind.)

Signed-off-by: Dima Ryazanov <d...@gmail.com>
---
 libweston/compositor-wayland.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libweston/compositor-wayland.c b/libweston/compositor-wayland.c
index f51f78dd..111c4c09 100644
--- a/libweston/compositor-wayland.c
+++ b/libweston/compositor-wayland.c
@@ -1707,6 +1707,7 @@ input_handle_axis(void *data, struct wl_pointer *pointer,
 
weston_event.axis = axis;
weston_event.value = wl_fixed_to_double(value);
+   weston_event.has_discrete = false;
 
if (axis == WL_POINTER_AXIS_VERTICAL_SCROLL &&
input->vert.has_discrete) {
-- 
2.14.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] Add a missing error check to weston_wm_handle_icon

[Dima Ryazanov]

This fixes a crash when launching Duke Nukem Forever.
(Sorry, I wish I had a less ridiculous test case...)

Signed-off-by: Dima Ryazanov <d...@gmail.com>
---
 xwayland/window-manager.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c307e199..e9c60c1e 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1368,6 +1368,9 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
  wm->atom.net_wm_icon, XCB_ATOM_ANY, 0,
  UINT32_MAX);
reply = xcb_get_property_reply(wm->conn, cookie, NULL);
+   if (!reply)
+   return;
+
length = xcb_get_property_value_length(reply);
 
/* This is in 32-bit words, not in bytes. */
-- 
2.14.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] Add a help string for --xwayland

[Dima Ryazanov]

Signed-off-by: Dima Ryazanov <d...@gmail.com>
---
 compositor/main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/compositor/main.c b/compositor/main.c
index 18810f28..1e827884 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -469,6 +469,7 @@ usage(int error_code)
"  --shell=MODULE\tShell module, defaults to desktop-shell.so\n"
"  -S, --socket=NAME\tName of socket to listen on\n"
"  -i, --idle-time=SECS\tIdle time in seconds\n"
+   "  --xwayland\t\tLoad the xwayland module\n"
"  --modules\t\tLoad the comma-separated list of modules\n"
"  --log=FILE\t\tLog to the given file\n"
"  -c, --config=FILE\tConfig file to load, defaults to 
weston.ini\n"
-- 
2.14.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Subscribed or not?

[Dima Ryazanov]

Looks like you're in. Welcome!

On Tue, Nov 21, 2017 at 11:08 PM, Jari Vuomajoki 
wrote:

> Hello!
>
> I have now subscribed two times for the list, without getting any
> confirmation...
>
> So am I in or not?
>
> Best Wishes,
> Jari Vuomajoki
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] tools: replace the tap time measuring tool with a python one

[Dima Ryazanov]

Oh nice, much simpler. I have a few nitpick comments, but it looks good,
and works for me.

Reviewed-By: Dima Ryazanov <d...@gmail.com>
Tested-By: Dima Ryazanov <d...@gmail.com>

On Thu, Nov 16, 2017 at 1:11 PM, Peter Hutterer <peter.hutte...@who-t.net>
wrote:

> A lot easier to process data in python than in C.
>
> Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
> ---
>  meson.build   |  10 +-
>  tools/libinput-measure-touchpad-tap   | 261 +
>  tools/libinput-measure-touchpad-tap.c | 509
> --
>  3 files changed, 263 insertions(+), 517 deletions(-)
>  create mode 100755 tools/libinput-measure-touchpad-tap
>  delete mode 100644 tools/libinput-measure-touchpad-tap.c
>
> diff --git a/meson.build b/meson.build
> index eefe3d61..4d433989 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -414,14 +414,8 @@ configure_file(input : 'tools/libinput-measure.man',
>install_dir : join_paths(get_option('mandir'), 'man1')
>)
>
> -libinput_measure_touchpad_tap_sources = [ 
> 'tools/libinput-measure-touchpad-tap.c'
> ]
> -executable('libinput-measure-touchpad-tap',
> -  libinput_measure_touchpad_tap_sources,
> -  dependencies : deps_tools,
> -  include_directories : [includes_src, includes_include],
> -  install_dir : libinput_tool_path,
> -  install : true,
> -  )
> +install_data('tools/libinput-measure-touchpad-tap',
> +install_dir : libinput_tool_path)
>  configure_file(input : 'tools/libinput-measure-touchpad-tap.man',
>output : 'libinput-measure-touchpad-tap.1',
>configuration : man_config,
> diff --git a/tools/libinput-measure-touchpad-tap
> b/tools/libinput-measure-touchpad-tap
> new file mode 100755
> index ..165cd65a
> --- /dev/null
> +++ b/tools/libinput-measure-touchpad-tap
> @@ -0,0 +1,261 @@
> +#!/usr/bin/python3
> +# vim: set expandtab shiftwidth=4:
> +# -*- Mode: python; coding: utf-8; indent-tabs-mode: nil -*- */
> +#
> +# Copyright © 2017 Red Hat, Inc.
> +#
> +# Permission is hereby granted, free of charge, to any person obtaining a
> +# copy of this software and associated documentation files (the
> "Software"),
> +# to deal in the Software without restriction, including without
> limitation
> +# the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +# and/or sell copies of the Software, and to permit persons to whom the
> +# Software is furnished to do so, subject to the following conditions:
> +#
> +# The above copyright notice and this permission notice (including the
> next
> +# paragraph) shall be included in all copies or substantial portions of
> the
> +# Software.
> +#
> +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> OR
> +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +# DEALINGS IN THE SOFTWARE.
> +#
> +
> +import sys
> +import argparse
> +try:
> +import evdev
> +import evdev.ecodes
> +import textwrap
> +import pyudev
> +except ModuleNotFoundError as e:
> +print('Error: {}'.format(str(e)), file=sys.stderr)
>

"str" is redundant here.


> +print('One or more python modules are missing. Please install those '
> +  'modules and re-run this tool.')
> +sys.exit(1)
> +
> +print_dest = sys.stdout
> +
> +
> +def error(msg, **kwargs):
> +print(msg, **kwargs, file=sys.stderr)
> +
> +
> +def msg(msg, **kwargs):
> +print(msg, **kwargs, file=print_dest, flush=True)
> +
> +
> +def tv2us(sec, usec):
> +return sec * 100 + usec
> +
> +
> +def us2ms(us):
> +return int(us/1000)
> +
> +
> +class Touch(object):
> +def __init__(self, down):
> +self._down = down
> +self._up = down
> +
> +@property
> +def up(self):
> +return us2ms(self._up)
> +
> +@up.setter
> +def up(self, up):
> +assert(up > self.down)
>

Should this be "up >= self.down"? Or is it not possible to have the same
timestamp?


> +self._up = up
> +
> +@property
> +def down(self):
> +return us2ms(self._down)
> +
> +@property
> +def tdelta(self):
> +return self.up - 

Re: Running multiple Wayland window managers in different ttys

[Dima Ryazanov]

What do you see if you run weston on tty3 (rather than sway), without
setting WAYLAND_SOCKET or --socket?

On Sat, Oct 21, 2017 at 12:02 AM, Dima Ryazanov <d...@gmail.com> wrote:

> 1. Actually, Weston *should* set the right wayland socket automatically.
> They're not mapped to ttys - but Weston tries them until it finds an
> available one (at least, in my case). I see the following in the log:
>
> [23:52:27.077] libwayland: unable to lock lockfile
> /run/user/1000/wayland-0.lock, maybe another compositor is running
>
> So to me, this looks like a bug in sway.
>
> 2. Setting "WAYLAND_DISPLAY=wayland-1" before running Weston causes
> Weston to try to connect to a parent compositor instead of running directly
> on top of the tty. But of course, there's no parent compositor listening on
> wayland-1.
> Yeah, setting --socket=wayland-1 should work - but, as I said above,
> shouldn't actually be necessary.
>
> 3. gnome-terminal works for me as expected, despite the server process.
> I'm not really familiar with it, though.
>
> On Fri, Oct 20, 2017 at 9:58 PM, Matt Hoosier <matt.hoos...@gmail.com>
> wrote:
>
>> Hi Deepak,
>>
>> On Fri, Oct 20, 2017 at 11:50 AM, Deepak Jois <deepak.j...@gmail.com>
>> wrote:
>> > Hi
>> >
>> > I have read the Wayland docs and skimmed through the API reference,
>> > and I am trying to understand some concepts better. The questions
>> > below are probably a bit naive, but I appreciate any
>> > suggestions/explanations.
>> >
>> > To illustrate my situation better, let me start with an actual
>> > scenario I tried to make work. I am trying to run Gnome and another
>> > Wayland-based window manager (Sway or Weston) in two different ttys as
>> > the same user.
>> >
>> > I have Gnome running under Wayland on tty2. The Gnome session is
>> > running some app like gnome-terminal.
>> >
>> > I do the following:
>> >
>> > * Press Ctrl-Alt-F3 (switching to tty3, the lowest free tty)
>> > * Login as the same user running the Gnome session
>> > * Launch sway
>> > * Launch urxvt and try to launch gnome-terminal.
>> >
>> > Now I have two issues I am trying to understand better:
>> >
>> > 1. When I check the WAYLAND_DISPLAY variable in the sway session, it
>> > shows 'wayland-0', which is the same as the one show in the Gnome
>> > session. Why is it the same? Does Wayland have a concept of multiple
>> > servers/sessions per user? Can I run the Gnome session and the Sway
>> > session separately?
>>
>> Although you're right that the goal here is to bind the different
>> Wayland sessions' values for WAYLAND_DISPLAY to unique virtual
>> terminals, that won't happen automatically just because you launched
>> them from separate tty's.
>>
>> The trick here is to inform each compositor that it should be
>> listening on a different Wayland socket name. For example, if you use
>> Weston:
>>
>> $ weston --socket=wayland-1
>>
>> This will cause Weston to establish its listening socket under the
>> name /run/user//wayland-1 rather than the default
>> /run/user//wayland-0. I think you're running into collisions
>> where each of your compositor instances is mislead into believing that
>> it successfully managed to appropriate /run/user//wayland-0 for
>> itself.
>>
>> Also (at least for Weston), the value of the '--socket' parameter is
>> used to automatically compute and set the value of the
>> $WAYLAND_DISPLAY environment variable which is then passed along to
>> all children of the compositor. Presumably for you, your desktop
>> environment (e.g., Weston's desktop-shell) is the starting point from
>> which you're launching other graphical programs. They will all in turn
>> inherit this correct value of $WAYLAND_DISPLAY too.
>>
>> >
>> > 2. I tried explicitly setting the WAYLAND_DISPLAY to wayland-1. It has
>> > no effect on Sway. The WAYLAND_DISPLAY variable is reset inside the
>> > session to wayland-0. But when I try to launch Weston, it errors out
>> > (log below). Is this expected, or is this a bug?
>>
>> The way to get Weston to pass the right value of WAYLAND_DISPLAY to
>> its spawn is to use --socket=.
>>
>> It's more difficult to invoke the Wayland gnome-session directly. I'm
>> not sure how you would micromanage its selection of the server socket
>> name.
>>
>> -Matt
>> ___
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Running multiple Wayland window managers in different ttys

[Dima Ryazanov]

1. Actually, Weston *should* set the right wayland socket automatically.
They're not mapped to ttys - but Weston tries them until it finds an
available one (at least, in my case). I see the following in the log:

[23:52:27.077] libwayland: unable to lock lockfile
/run/user/1000/wayland-0.lock, maybe another compositor is running

So to me, this looks like a bug in sway.

2. Setting "WAYLAND_DISPLAY=wayland-1" before running Weston causes Weston
to try to connect to a parent compositor instead of running directly on top
of the tty. But of course, there's no parent compositor listening on
wayland-1.
Yeah, setting --socket=wayland-1 should work - but, as I said above,
shouldn't actually be necessary.

3. gnome-terminal works for me as expected, despite the server process. I'm
not really familiar with it, though.

On Fri, Oct 20, 2017 at 9:58 PM, Matt Hoosier 
wrote:

> Hi Deepak,
>
> On Fri, Oct 20, 2017 at 11:50 AM, Deepak Jois 
> wrote:
> > Hi
> >
> > I have read the Wayland docs and skimmed through the API reference,
> > and I am trying to understand some concepts better. The questions
> > below are probably a bit naive, but I appreciate any
> > suggestions/explanations.
> >
> > To illustrate my situation better, let me start with an actual
> > scenario I tried to make work. I am trying to run Gnome and another
> > Wayland-based window manager (Sway or Weston) in two different ttys as
> > the same user.
> >
> > I have Gnome running under Wayland on tty2. The Gnome session is
> > running some app like gnome-terminal.
> >
> > I do the following:
> >
> > * Press Ctrl-Alt-F3 (switching to tty3, the lowest free tty)
> > * Login as the same user running the Gnome session
> > * Launch sway
> > * Launch urxvt and try to launch gnome-terminal.
> >
> > Now I have two issues I am trying to understand better:
> >
> > 1. When I check the WAYLAND_DISPLAY variable in the sway session, it
> > shows 'wayland-0', which is the same as the one show in the Gnome
> > session. Why is it the same? Does Wayland have a concept of multiple
> > servers/sessions per user? Can I run the Gnome session and the Sway
> > session separately?
>
> Although you're right that the goal here is to bind the different
> Wayland sessions' values for WAYLAND_DISPLAY to unique virtual
> terminals, that won't happen automatically just because you launched
> them from separate tty's.
>
> The trick here is to inform each compositor that it should be
> listening on a different Wayland socket name. For example, if you use
> Weston:
>
> $ weston --socket=wayland-1
>
> This will cause Weston to establish its listening socket under the
> name /run/user//wayland-1 rather than the default
> /run/user//wayland-0. I think you're running into collisions
> where each of your compositor instances is mislead into believing that
> it successfully managed to appropriate /run/user//wayland-0 for
> itself.
>
> Also (at least for Weston), the value of the '--socket' parameter is
> used to automatically compute and set the value of the
> $WAYLAND_DISPLAY environment variable which is then passed along to
> all children of the compositor. Presumably for you, your desktop
> environment (e.g., Weston's desktop-shell) is the starting point from
> which you're launching other graphical programs. They will all in turn
> inherit this correct value of $WAYLAND_DISPLAY too.
>
> >
> > 2. I tried explicitly setting the WAYLAND_DISPLAY to wayland-1. It has
> > no effect on Sway. The WAYLAND_DISPLAY variable is reset inside the
> > session to wayland-0. But when I try to launch Weston, it errors out
> > (log below). Is this expected, or is this a bug?
>
> The way to get Weston to pass the right value of WAYLAND_DISPLAY to
> its spawn is to use --socket=.
>
> It's more difficult to invoke the Wayland gnome-session directly. I'm
> not sure how you would micromanage its selection of the server socket
> name.
>
> -Matt
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 3/6] launcher-logind: only get a VT on seat0, as only seat0 supports VTs

[Dima Ryazanov]

On Tue, Oct 3, 2017 at 7:28 PM, nerdopolis 
wrote:

> As only seat0 supports TTYs, this changes the logind launcher where
> it detects a TTY, only if the seat is seat0. This has only been
> tested for logind
> ---
>  libweston/launcher-logind.c | 22 --
>  libweston/launcher-util.c   |  4 
>  2 files changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/libweston/launcher-logind.c b/libweston/launcher-logind.c
> index a069bd4f..a94ec0e9 100644
> --- a/libweston/launcher-logind.c
> +++ b/libweston/launcher-logind.c
> @@ -762,18 +762,20 @@ launcher_logind_connect(struct weston_launcher
> **out, struct weston_compositor *
> free(t);
> goto err_session;
> }
> -   free(t);
>
> -   r = weston_sd_session_get_vt(wl->sid, >vtnr);
> -   if (r < 0) {
> -   weston_log("logind: session not running on a VT\n");
> -   goto err_session;
> -   } else if (tty > 0 && wl->vtnr != (unsigned int )tty) {
> -   weston_log("logind: requested VT --tty=%d differs from
> real session VT %u\n",
> -  tty, wl->vtnr);
> -   r = -EINVAL;
> -   goto err_session;
> +   if (!strcmp(t, "seat0")) {
> +   r = weston_sd_session_get_vt(wl->sid, >vtnr);
> +   if (r < 0) {
> +   weston_log("logind: session not running on a
> VT\n");
> +   goto err_session;
> +   } else if (tty > 0 && wl->vtnr != (unsigned int )tty) {
> +   weston_log("logind: requested VT --tty=%d differs
> from real session VT %u\n",
> +  tty, wl->vtnr);
> +   r = -EINVAL;
> +   goto err_session;
> +   }
> }
> +   free(t);
>

You will now need to free it before the two "goto err_session;" statements
above, too.


>
> loop = wl_display_get_event_loop(compositor->wl_display);
> r = weston_dbus_open(loop, DBUS_BUS_SYSTEM, >dbus,
> >dbus_ctx);
> diff --git a/libweston/launcher-util.c b/libweston/launcher-util.c
> index fa3ed13b..848c6ade 100644
> --- a/libweston/launcher-util.c
> +++ b/libweston/launcher-util.c
> @@ -111,6 +111,10 @@ WL_EXPORT void
>  weston_setup_vt_switch_bindings(struct weston_compositor *compositor)
>  {
> uint32_t key;
> +   struct weston_launcher *launcher = compositor->launcher;
> +
> +   if (launcher->iface->get_vt(launcher) == 0)
> +   return;
>
> if (compositor->vt_switching == false)
> return;
> --
> 2.14.1
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] evdev: replace null sentinel with ARRAY_SIZE

[Dima Ryazanov]

On May 10, 2017 7:14 AM, "Eric Engestrom"  wrote:

Signed-off-by: Eric Engestrom 
---
 src/evdev.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index a2be6fc..7895644 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -50,6 +50,8 @@
 #define DEFAULT_WHEEL_CLICK_ANGLE 15
 #define DEFAULT_BUTTON_SCROLL_TIMEOUT ms2us(200)

+#define ARRAY_SIZE(a) (sizeof(a)/sizeof(a)[0])


I'm guessing this works, but "sizeof(a)[0]" looks very unintuitive to me. I
think "sizeof(a[0])" is the convention?

+
 enum evdev_key_type {
EVDEV_KEY_TYPE_NONE,
EVDEV_KEY_TYPE_KEY,
@@ -90,9 +92,6 @@ static const struct evdev_udev_tag_match
evdev_udev_tag_matches[] = {
{"ID_INPUT_POINTINGSTICK",  EVDEV_UDEV_TAG_POINTINGSTICK},
{"ID_INPUT_TRACKBALL",  EVDEV_UDEV_TAG_TRACKBALL},
{"ID_INPUT_SWITCH", EVDEV_UDEV_TAG_SWITCH},
-
-   /* sentinel value */
-   {0, 0},
 };

 static inline bool
@@ -2373,18 +2372,16 @@ evdev_device_get_udev_tags(struct evdev_device
*device,
   struct udev_device *udev_device)
 {
enum evdev_device_udev_tags tags = 0;
-   const struct evdev_udev_tag_match *match;
int i;

for (i = 0; i < 2 && udev_device; i++) {
-   match = evdev_udev_tag_matches;
-   while (match->name) {
+   unsigned j;
+   for (j = 0; j < ARRAY_SIZE(evdev_udev_tag_matches); j++) {
+   const struct evdev_udev_tag_match match =
evdev_udev_tag_matches[j];
if (parse_udev_flag(device,
udev_device,
-   match->name))
-   tags |= match->tag;
-
-   match++;
+   match.name))
+   tags |= match.tag;
}
udev_device = udev_device_get_parent(udev_device);
}
--
Cheers,
  Eric

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 0/2] xdg-shell: Proposal to be more generic for decorations

[Dima Ryazanov]

Overall, I like the idea - it seems to solve the issues with raise/lower,
etc.

I wonder, though, if removing the explicit move/resize/etc. requests makes
it too restrictive. Suppose that, for whatever reason, the client wants to
trigger a move or a resize using the right or middle button. Maybe it's a
weirdly-shaped surface (like weston-flower) where all of it is draggable,
or some other strange case. As far as I can tell, it's possible in v6, but
not v7.

Another, more real use case: nautilus has a bunch of buttons in the
titlebar. If you click them, they work as usual - but dragging a button
triggers a shell move. That means, at the time the client receives a mouse
down event, it doesn't know yet what it should do. Once it gets a mouse
move, it sends a shell move request. Would that still be possible in v7?


On Fri, Dec 9, 2016 at 2:20 PM, Adam Goode  wrote:

> Hi,
>
> There were many different opinions and suggestions for how to allow
> for raise and lower to be bound to mouse clicks in titlebars. This
> is one possible way forward. It removes some of the semantic requests
> in xdg-shell and replaces it with a "interact_with_decoration"
> request that lets more window management logic move into the compositor.
>
> Comments welcome. I know this is a tricky issue, but I hope this
> is leading somewhat in the right direction.
>
>
> Adam
>
>
>
> Adam Goode (2):
>   xdg-shell: Introduce protocol v7
>   xdg-shell: Fold several client-side decoration requests into a generic
> request
>
>  COPYING  |1 +
>  unstable/xdg-shell/xdg-shell-unstable-v7.xml | 1012
> ++
>  2 files changed, 1013 insertions(+)
>  create mode 100644 unstable/xdg-shell/xdg-shell-unstable-v7.xml
>
> --
> 2.8.0.rc3.226.g39d4020
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/6] libweston: Use the monotonic clock in weston_compositor_get_time

[Dima Ryazanov]

On Tue, Dec 6, 2016 at 3:32 AM, Daniel Stone <dan...@fooishbar.org> wrote:

> Hi,
>
> On 5 December 2016 at 03:36, Dima Ryazanov <d...@gmail.com> wrote:
> > (This is kind of a workaround, but perhaps the right thing to do
> anyways.)
> >
> > The menu implementation in window.c needs to know the time of the event
> that
> > triggered the menu - however, the xdg-shell's show_window_menu API does
> not
> > give us that info. There doesn't seem to be an easy way to fake it
> because
> > different compositors use different times when sending events:
> > - compositor-drm uses the monotonic clock
> > - compositor-x11 uses weston_compositor_get_time
> > - compositor-wayland uses the event times in got from the parent
> compositor
> > - GNOME appears to use the monotonic clock
> >
> > Switching weston_compositor_get_time to use the monotonic clock works
> around
> > this issue - though things would break in compositor-wayland if its
> parent
> > uses something else.
> >
> > Signed-off-by: Dima Ryazanov <d...@gmail.com>
>
> I think we may want a check that CLOCK_MONOTONIC actually works (i.e.
> the first time this function is called, assert that ret == 0). But
> yes, it's definitely the right thing to do, so with that:
> Reviewed-by: Daniel Stone <dani...@collabora.com>
>

If we're going to assert, do you think it's ok to just assert every time?
That would make the logic simpler - and it doesn't look like it could
succeed once, then fail later.

Though almost all of the existing code just ignores the return value. It
would be good to either handle failures everywhere, or just assert that the
clock works when Weston starts up.

Cheers,
> Daniel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 5/6] Display the window menu using the desktop shell

[Dima Ryazanov]

The compositor creates a resource that gives the desktop shell limited access
to the window that requested a window menu, and sends the desktop shell a
"show_window_menu" event. The desktop shell then displays a popup menu using
the usual window APIs, and sends back a request with the result (only "Close"
for now).

This patch is hacky and not quite finished - but I'd like to get some feedback
first, to make sure this is the correct approach.

Signed-off-by: Dima Ryazanov <d...@gmail.com>
---
 clients/desktop-shell.c   | 45 +++--
 clients/window.c  | 47 +--
 clients/window.h  | 10 +++
 desktop-shell/shell.c | 49 +++-
 desktop-shell/shell.h |  2 ++
 libweston-desktop/internal.h  |  5 
 libweston-desktop/libweston-desktop.h |  7 +
 libweston-desktop/surface.c   | 30 
 libweston-desktop/xdg-shell-v6.c  | 53 +++
 protocol/weston-desktop-shell.xml | 12 
 10 files changed, 255 insertions(+), 5 deletions(-)

diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index a1cf51d..e12171f 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -50,7 +50,8 @@
 #include "shared/xalloc.h"
 #include "shared/zalloc.h"
 
-#include "weston-desktop-shell-client-protocol.h"
+#include "xdg-shell-unstable-v6-client-protocol.h"
+#include "weston-desktop-shell-client-protocol.h"  /* XXX: Relies on the 
include order */
 
 #define DEFAULT_CLOCK_FORMAT CLOCK_FORMAT_MINUTES
 
@@ -1071,10 +1072,50 @@ desktop_shell_grab_cursor(void *data,
}
 }
 
+static void
+frame_menu_func(void *data, struct input *input, int index)
+{
+   struct window *window = data;
+   struct weston_desktop_shell *desktop_shell = 
window_get_user_data(window);
+
+   switch (index) {
+   case 0: /* close */
+   weston_desktop_shell_window_menu_close(desktop_shell);
+   break;
+   }
+
+   window_destroy(window);
+}
+
+static void
+desktop_shell_show_window_menu(void *data,
+  struct weston_desktop_shell *desktop_shell,
+  struct zxdg_surface_v6 *parent_surface,
+  struct wl_seat *seat, uint32_t serial, uint32_t 
time,
+  int32_t x, int32_t y)
+{
+   struct desktop *desktop = data;
+   struct window *parent = window_create_foreign(desktop->display,
+ parent_surface);
+   struct input *input = find_input_for_seat(desktop->display, seat);
+
+   static const char *entries[] = {
+   "Close",
+   };
+
+   assert(input);
+
+   window_set_user_data(parent, desktop_shell);
+
+   window_show_menu(desktop->display, input, serial, time, parent, x, y,
+frame_menu_func, entries, ARRAY_LENGTH(entries));
+}
+
 static const struct weston_desktop_shell_listener listener = {
desktop_shell_configure,
desktop_shell_prepare_lock_surface,
-   desktop_shell_grab_cursor
+   desktop_shell_grab_cursor,
+   desktop_shell_show_window_menu
 };
 
 static void
diff --git a/clients/window.c b/clients/window.c
index 12884f4..d4eeca6 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -1558,7 +1558,8 @@ surface_destroy(struct surface *surface)
if (surface->subsurface)
wl_subsurface_destroy(surface->subsurface);
 
-   wl_surface_destroy(surface->surface);
+   if (surface->surface)
+   wl_surface_destroy(surface->surface);
 
if (surface->toysurface)
surface->toysurface->destroy(surface->toysurface);
@@ -3540,6 +3541,18 @@ input_get_focus_widget(struct input *input)
return input->focus_widget;
 }
 
+struct input *
+find_input_for_seat(struct display *display, struct wl_seat *seat)
+{
+   struct input *input = NULL;
+
+   wl_list_for_each(input, >input_list, link) {
+   if (input_get_seat(input) == seat)
+   return input;
+   }
+   return NULL;
+}
+
 struct data_offer {
struct wl_data_offer *offer;
struct input *input;
@@ -5213,7 +5226,7 @@ window_create_internal(struct display *display, int 
custom)
wl_list_insert(display->window_list.prev, >link);
wl_list_init(>redraw_task.link);
 
-   wl_list_init (>window_output_list);
+   wl_list_init(>window_output_list);
 
return window;
 }
@@ -5266,6 +5279,36 @@ window_create_custom(struct display *display)
return window_create_internal(display, 1);
 }
 
+struct window *
+window_create_foreign(struct display *display, struct zxdg_surface_v6 
*x

[PATCH weston 6/6] window: Start using xdg-shell's show_window_menu API

[Dima Ryazanov]

We lose the "Fullscreen" menu item, but oh well.

Signed-off-by: Dima Ryazanov <d...@gmail.com>
---
 clients/window.c | 40 +++-
 1 file changed, 7 insertions(+), 33 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index d4eeca6..4c494b5 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -2324,45 +2324,19 @@ frame_get_pointer_image_for_location(struct 
window_frame *frame,
}
 }
 
-static void
-frame_menu_func(void *data, struct input *input, int index)
-{
-   struct window *window = data;
-
-   switch (index) {
-   case 0: /* close */
-   window_close(window);
-   break;
-   case 1: /* fullscreen */
-   /* we don't have a way to get out of fullscreen for now */
-   if (window->fullscreen_handler)
-   window->fullscreen_handler(window, window->user_data);
-   break;
-   }
-}
-
 void
 window_show_frame_menu(struct window *window,
-  struct input *input, uint32_t time)
+  struct input *input,
+  uint32_t time)
 {
int32_t x, y;
-   int count;
-
-   static const char *entries[] = {
-   "Close",
-   "Fullscreen"
-   };
-
-   if (window->fullscreen_handler)
-   count = ARRAY_LENGTH(entries);
-   else
-   count = ARRAY_LENGTH(entries) - 1;
 
input_get_position(input, , );
-   window_show_menu(window->display, input,
-display_get_serial(window->display),
-time, window,
-x - 10, y - 10, frame_menu_func, entries, count);
+
+   zxdg_toplevel_v6_show_window_menu(window->xdg_toplevel,
+ input_get_seat(input),
+ window->display->serial,
+ x, y);
 }
 
 static int
-- 
2.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 3/6] window: Require the serial in window_show_menu

[Dima Ryazanov]

The serial that triggered the menu may not always be the latest serial - as will
be the case for the desktop-shell. Let's just require clients to pass it
explicitly. They already do it when starting a grab, moving a window, etc.

Signed-off-by: Dima Ryazanov <d...@gmail.com>
---
 clients/editor.c   |  4 +++-
 clients/resizor.c  |  4 +++-
 clients/stacking.c |  4 +++-
 clients/terminal.c |  4 +++-
 clients/window.c   | 12 ++--
 clients/window.h   |  4 ++--
 6 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/clients/editor.c b/clients/editor.c
index 42c7f52..a201eff 100644
--- a/clients/editor.c
+++ b/clients/editor.c
@@ -683,7 +683,9 @@ show_menu(struct editor *editor, struct input *input, 
uint32_t time)
};
 
input_get_position(input, , );
-   window_show_menu(editor->display, input, time, editor->window,
+   window_show_menu(editor->display, input,
+display_get_serial(editor->display),
+time, editor->window,
 x + 10, y + 20, menu_func,
 entries, ARRAY_LENGTH(entries));
 }
diff --git a/clients/resizor.c b/clients/resizor.c
index 5d342e1..481b9f0 100644
--- a/clients/resizor.c
+++ b/clients/resizor.c
@@ -221,7 +221,9 @@ show_menu(struct resizor *resizor, struct input *input, 
uint32_t time)
};
 
input_get_position(input, , );
-   window_show_menu(resizor->display, input, time, resizor->window,
+   window_show_menu(resizor->display, input,
+display_get_serial(resizor->display),
+time, resizor->window,
 x - 10, y - 10, menu_func, entries, 4);
 }
 
diff --git a/clients/stacking.c b/clients/stacking.c
index 0682e60..246ef59 100644
--- a/clients/stacking.c
+++ b/clients/stacking.c
@@ -102,7 +102,9 @@ show_popup(struct stacking *stacking, struct input *input, 
uint32_t time,
};
 
input_get_position(input, , );
-   window_show_menu(stacking->display, input, time, window, x, y,
+   window_show_menu(stacking->display, input,
+display_get_serial(stacking->display),
+time, window, x, y,
 show_popup_cb, entries, ARRAY_LENGTH(entries));
 }
 
diff --git a/clients/terminal.c b/clients/terminal.c
index 5c25fa8..b12d334 100644
--- a/clients/terminal.c
+++ b/clients/terminal.c
@@ -2725,7 +2725,9 @@ show_menu(struct terminal *terminal, struct input *input, 
uint32_t time)
};
 
input_get_position(input, , );
-   window_show_menu(terminal->display, input, time, terminal->window,
+   window_show_menu(terminal->display, input,
+display_get_serial(terminal->display),
+time, terminal->window,
 x - 10, y - 10, menu_func,
 entries, ARRAY_LENGTH(entries));
 }
diff --git a/clients/window.c b/clients/window.c
index afc7cab..f49ce72 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -2358,7 +2358,9 @@ window_show_frame_menu(struct window *window,
count = ARRAY_LENGTH(entries) - 1;
 
input_get_position(input, , );
-   window_show_menu(window->display, input, time, window,
+   window_show_menu(window->display, input,
+display_get_serial(window->display),
+time, window,
 x - 10, y - 10, frame_menu_func, entries, count);
 }
 
@@ -5499,8 +5501,8 @@ create_simple_positioner(struct display *display,
 
 void
 window_show_menu(struct display *display,
-struct input *input, uint32_t time, struct window *parent,
-int32_t x, int32_t y,
+struct input *input, uint32_t serial, uint32_t time,
+struct window *parent, int32_t x, int32_t y,
 menu_func_t func, const char **entries, int count)
 {
struct menu *menu;
@@ -5547,9 +5549,7 @@ window_show_menu(struct display *display,
  positioner);
fail_on_null(window->xdg_popup, 0, __FILE__, __LINE__);
zxdg_positioner_v6_destroy(positioner);
-   zxdg_popup_v6_grab(window->xdg_popup,
-  input->seat,
-  display_get_serial(window->display));
+   zxdg_popup_v6_grab(window->xdg_popup, input->seat, serial);
zxdg_popup_v6_add_listener(window->xdg_popup,
   _popup_listener, window);
 
diff --git a/clients/window.h b/clients/window.h
index 1ec9eac..1cb3d27 100644
--- a/clients/window.h
+++ b/clients/window.h
@@ -324,8 +324,8 @@ typedef void (*menu_func_t)(void *data, struct input 
*input, int index);
 
 void
 window_show_menu(struct display *display,
-struct input *input, uint32_t time, struct window *parent,
-

[PATCH weston 1/6] libweston: Pass the serial along with the other data in the show_window_menu API

[Dima Ryazanov]

We'll need it later to actually display a popup menu.

Signed-off-by: Dima Ryazanov <d...@gmail.com>
---
 libweston-desktop/internal.h  | 2 +-
 libweston-desktop/libweston-desktop.c | 4 ++--
 libweston-desktop/libweston-desktop.h | 4 ++--
 libweston-desktop/xdg-shell-v5.c  | 3 ++-
 libweston-desktop/xdg-shell-v6.c  | 2 +-
 5 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/libweston-desktop/internal.h b/libweston-desktop/internal.h
index a9c974b..e7044a4 100644
--- a/libweston-desktop/internal.h
+++ b/libweston-desktop/internal.h
@@ -54,7 +54,7 @@ void
 weston_desktop_api_show_window_menu(struct weston_desktop *desktop,
struct weston_desktop_surface *surface,
struct weston_seat *seat,
-   int32_t x, int32_t y);
+   uint32_t serial, int32_t x, int32_t y);
 void
 weston_desktop_api_set_parent(struct weston_desktop *desktop,
  struct weston_desktop_surface *surface,
diff --git a/libweston-desktop/libweston-desktop.c 
b/libweston-desktop/libweston-desktop.c
index 0ee1139..c867d73 100644
--- a/libweston-desktop/libweston-desktop.c
+++ b/libweston-desktop/libweston-desktop.c
@@ -178,10 +178,10 @@ void
 weston_desktop_api_show_window_menu(struct weston_desktop *desktop,
struct weston_desktop_surface *surface,
struct weston_seat *seat,
-   int32_t x, int32_t y)
+   uint32_t serial, int32_t x, int32_t y)
 {
if (desktop->api.show_window_menu != NULL)
-   desktop->api.show_window_menu(surface, seat, x, y,
+   desktop->api.show_window_menu(surface, seat, serial, x, y,
  desktop->user_data);
 }
 
diff --git a/libweston-desktop/libweston-desktop.h 
b/libweston-desktop/libweston-desktop.h
index f77ab55..befecdf 100644
--- a/libweston-desktop/libweston-desktop.h
+++ b/libweston-desktop/libweston-desktop.h
@@ -62,8 +62,8 @@ struct weston_desktop_api {
void (*committed)(struct weston_desktop_surface *surface,
  int32_t sx, int32_t sy, void *user_data);
void (*show_window_menu)(struct weston_desktop_surface *surface,
-struct weston_seat *seat, int32_t x, int32_t y,
-void *user_data);
+struct weston_seat *seat, uint32_t serial,
+int32_t x, int32_t y, void *user_data);
void (*set_parent)(struct weston_desktop_surface *surface,
   struct weston_desktop_surface *parent,
   void *user_data);
diff --git a/libweston-desktop/xdg-shell-v5.c b/libweston-desktop/xdg-shell-v5.c
index 08cf71e..9074e4b 100644
--- a/libweston-desktop/xdg-shell-v5.c
+++ b/libweston-desktop/xdg-shell-v5.c
@@ -362,7 +362,8 @@ weston_desktop_xdg_surface_protocol_show_window_menu(struct 
wl_client *wl_client
weston_desktop_surface_get_implementation_data(dsurface);
 
weston_desktop_xdg_surface_ensure_added(surface);
-   weston_desktop_api_show_window_menu(surface->desktop, dsurface, seat, 
x, y);
+   weston_desktop_api_show_window_menu(surface->desktop,
+   dsurface, seat, serial, x, y);
 }
 
 static void
diff --git a/libweston-desktop/xdg-shell-v6.c b/libweston-desktop/xdg-shell-v6.c
index 30f6d82..cab9808 100644
--- a/libweston-desktop/xdg-shell-v6.c
+++ b/libweston-desktop/xdg-shell-v6.c
@@ -365,7 +365,7 @@ 
weston_desktop_xdg_toplevel_protocol_show_window_menu(struct wl_client *wl_clien
}
 
weston_desktop_api_show_window_menu(toplevel->base.desktop,
-   dsurface, seat, x, y);
+   dsurface, seat, serial, x, y);
 }
 
 static void
-- 
2.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 4/6] window: Call the menu callback even if the menu was dismissed

[Dima Ryazanov]

Desktop shell will need to know when to clean up menu-related resources.
Other clients might find it useful, too.

Signed-off-by: Dima Ryazanov <d...@gmail.com>
---
 clients/window.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/clients/window.c b/clients/window.c
index f49ce72..12884f4 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -5359,6 +5359,7 @@ menu_touch_up_handler(struct widget *widget,
 {
struct menu *menu = data;
 
+   menu->func(menu->user_data, input, -1);
input_ungrab(input);
menu_destroy(menu);
 }
@@ -5419,6 +5420,7 @@ xdg_popup_handle_popup_done(void *data, struct 
zxdg_popup_v6 *xdg_popup)
struct window *window = data;
struct menu *menu = window->main_surface->widget->user_data;
 
+   menu->func(menu->user_data, menu->input, -1);
input_ungrab(menu->input);
menu_destroy(menu);
 }
-- 
2.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 0/6] Implement xdg-shell's show_window_menu API

[Dima Ryazanov]

This series implements window menus in Weston - so e.g. right-clicking
the title bar of a Gnome app in Weston will actually show a popup menu.
The last patch makes Weston clients use the same API, so they'll get
a native-looking menu when running in Gnome.

Patches 1, 3, and 4 should be pretty uncontroversial.
Patch 2 is a hack, but might be correct anyways.
Patch 5 is where all the work is done. It's still a work-in-progress, but
  I'd like to get some feedback.
Patch 6 doesn't technically depend on 1-5, but will be sort of a regression
  without them.

Known bugs:
- The menu is displayed at an offset
- When Gnome apps display the menu, it looks like the grab stays around even
  after the menu is dismissed; you have to click again before you can do
  anything else.

Dima Ryazanov (6):
  libweston: Pass the serial along with the other data in the
show_window_menu API
  libweston: Use the monotonic clock in weston_compositor_get_time
  window: Require the serial in window_show_menu
  window: Call the menu callback even if the menu was dismissed
  Display the window menu using the desktop shell
  window: Start using xdg-shell's show_window_menu API

 clients/desktop-shell.c   | 46 -
 clients/editor.c  |  4 +-
 clients/resizor.c |  4 +-
 clients/stacking.c|  4 +-
 clients/terminal.c|  4 +-
 clients/window.c  | 95 +--
 clients/window.h  | 14 +-
 desktop-shell/shell.c | 49 +-
 desktop-shell/shell.h |  2 +
 libweston-desktop/internal.h  |  7 ++-
 libweston-desktop/libweston-desktop.c |  4 +-
 libweston-desktop/libweston-desktop.h | 11 +++-
 libweston-desktop/surface.c   | 30 +++
 libweston-desktop/xdg-shell-v5.c  |  3 +-
 libweston-desktop/xdg-shell-v6.c  | 55 +++-
 libweston/compositor.c|  6 +--
 protocol/weston-desktop-shell.xml | 12 +
 17 files changed, 293 insertions(+), 57 deletions(-)

-- 
2.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 2/6] libweston: Use the monotonic clock in weston_compositor_get_time

[Dima Ryazanov]

(This is kind of a workaround, but perhaps the right thing to do anyways.)

The menu implementation in window.c needs to know the time of the event that
triggered the menu - however, the xdg-shell's show_window_menu API does not
give us that info. There doesn't seem to be an easy way to fake it because
different compositors use different times when sending events:
- compositor-drm uses the monotonic clock
- compositor-x11 uses weston_compositor_get_time
- compositor-wayland uses the event times in got from the parent compositor
- GNOME appears to use the monotonic clock

Switching weston_compositor_get_time to use the monotonic clock works around
this issue - though things would break in compositor-wayland if its parent
uses something else.

Signed-off-by: Dima Ryazanov <d...@gmail.com>
---
 libweston/compositor.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index 6457858..aa4bf345 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -1693,11 +1693,11 @@ weston_surface_update_size(struct weston_surface 
*surface)
 WL_EXPORT uint32_t
 weston_compositor_get_time(void)
 {
-   struct timeval tv;
+   struct timespec ts;
 
-   gettimeofday(, NULL);
+   clock_gettime(CLOCK_MONOTONIC, );
 
-   return tv.tv_sec * 1000 + tv.tv_usec / 1000;
+   return ts.tv_sec * 1000 + ts.tv_nsec / 100;
 }
 
 WL_EXPORT struct weston_view *
-- 
2.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] xdg-shell: Add NULL checks for resources that may have gone away.

[Dima Ryazanov]

This should fix some (fairly rare) crashes where the client goes away at exactly
the wrong moment, e.g.:
- Weston sends a message to the client
- Message causes the client to crash for whatever reason
- Weston keeps processing the remaining requests from the now dead client

(I've only seen it happen once, while stepping through Weston's code in gdb, but
seems like the right thing to fix.)

Signed-off-by: Dima Ryazanov <d...@gmail.com>
---
 libweston-desktop/xdg-shell-v6.c | 141 ---
 1 file changed, 101 insertions(+), 40 deletions(-)

diff --git a/libweston-desktop/xdg-shell-v6.c b/libweston-desktop/xdg-shell-v6.c
index 7d0bd8e..30f6d82 100644
--- a/libweston-desktop/xdg-shell-v6.c
+++ b/libweston-desktop/xdg-shell-v6.c
@@ -302,10 +302,14 @@ weston_desktop_xdg_toplevel_protocol_set_parent(struct 
wl_client *wl_client,
 {
struct weston_desktop_surface *dsurface =
wl_resource_get_user_data(resource);
-   struct weston_desktop_xdg_toplevel *toplevel =
-   weston_desktop_surface_get_implementation_data(dsurface);
+   struct weston_desktop_xdg_toplevel *toplevel;
struct weston_desktop_surface *parent = NULL;
 
+   if (!dsurface)
+   return;
+
+   toplevel = weston_desktop_surface_get_implementation_data(dsurface);
+
if (parent_resource != NULL)
parent = wl_resource_get_user_data(parent_resource);
 
@@ -346,8 +350,12 @@ 
weston_desktop_xdg_toplevel_protocol_show_window_menu(struct wl_client *wl_clien
wl_resource_get_user_data(resource);
struct weston_seat *seat =
wl_resource_get_user_data(seat_resource);
-   struct weston_desktop_xdg_toplevel *toplevel =
-   weston_desktop_surface_get_implementation_data(dsurface);
+   struct weston_desktop_xdg_toplevel *toplevel;
+
+   if (!dsurface)
+   return;
+
+   toplevel = weston_desktop_surface_get_implementation_data(dsurface);
 
if (!toplevel->base.configured) {
wl_resource_post_error(toplevel->resource,
@@ -370,8 +378,12 @@ weston_desktop_xdg_toplevel_protocol_move(struct wl_client 
*wl_client,
wl_resource_get_user_data(resource);
struct weston_seat *seat =
wl_resource_get_user_data(seat_resource);
-   struct weston_desktop_xdg_toplevel *toplevel =
-   weston_desktop_surface_get_implementation_data(dsurface);
+   struct weston_desktop_xdg_toplevel *toplevel;
+
+   if (!dsurface)
+   return;
+
+   toplevel = weston_desktop_surface_get_implementation_data(dsurface);
 
if (!toplevel->base.configured) {
wl_resource_post_error(toplevel->resource,
@@ -394,11 +406,15 @@ weston_desktop_xdg_toplevel_protocol_resize(struct 
wl_client *wl_client,
wl_resource_get_user_data(resource);
struct weston_seat *seat =
wl_resource_get_user_data(seat_resource);
-   struct weston_desktop_xdg_toplevel *toplevel =
-   weston_desktop_surface_get_implementation_data(dsurface);
+   struct weston_desktop_xdg_toplevel *toplevel;
enum weston_desktop_surface_edge surf_edges =
(enum weston_desktop_surface_edge) edges;
 
+   if (!dsurface)
+   return;
+
+   toplevel = weston_desktop_surface_get_implementation_data(dsurface);
+
if (!toplevel->base.configured) {
wl_resource_post_error(toplevel->resource,
   ZXDG_SURFACE_V6_ERROR_NOT_CONSTRUCTED,
@@ -423,9 +439,12 @@ weston_desktop_xdg_toplevel_protocol_set_min_size(struct 
wl_client *wl_client,
 {
struct weston_desktop_surface *dsurface =
wl_resource_get_user_data(resource);
-   struct weston_desktop_xdg_toplevel *toplevel =
-   weston_desktop_surface_get_implementation_data(dsurface);
+   struct weston_desktop_xdg_toplevel *toplevel;
 
+   if (!dsurface)
+   return;
+
+   toplevel = weston_desktop_surface_get_implementation_data(dsurface);
toplevel->next_min_size.width = width;
toplevel->next_min_size.height = height;
 }
@@ -437,9 +456,12 @@ weston_desktop_xdg_toplevel_protocol_set_max_size(struct 
wl_client *wl_client,
 {
struct weston_desktop_surface *dsurface =
wl_resource_get_user_data(resource);
-   struct weston_desktop_xdg_toplevel *toplevel =
-   weston_desktop_surface_get_implementation_data(dsurface);
+   struct weston_desktop_xdg_toplevel *toplevel;
+
+   if (!dsurface)
+   return;
 
+   toplevel = weston_desktop_surface_get_implementation_data(dsurface);
toplevel->next_max_size.width = width;
toplevel->next_max_size.height = height;
 }
@@ -450,9 +472,12 @@ weston_desktop_xdg_toplevel_protocol_set_maximized(struct 
wl_client *wl_client,
 {
str

[PATCH weston] window: Check for NULL surface in keyboard_handle_enter

[Dima Ryazanov]

This can happen if you right-click in weston-terminal a few times very quickly.
The pointer_handle_enter callback already checks for NULL, so let's do that in
keyboard_handle_enter, too.

Signed-off-by: Dima Ryazanov <d...@gmail.com>
---
 clients/window.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/clients/window.c b/clients/window.c
index ac35c3d..afc7cab 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -3084,6 +3084,11 @@ keyboard_handle_enter(void *data, struct wl_keyboard 
*keyboard,
struct input *input = data;
struct window *window;
 
+   if (!surface) {
+   /* enter event for a window we've just destroyed */
+   return;
+   }
+
input->display->serial = serial;
input->keyboard_focus = wl_surface_get_user_data(surface);
 
-- 
2.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] compositor-wayland: Destroy cursor images earlier

[Dima Ryazanov]

On Thu, Nov 24, 2016 at 7:32 AM, Daniel Stone <dani...@collabora.com> wrote:

> Destroying a wl_cursor will attempt to access the wl_display, which
> we have just freed. Avoid a segfault by destroying the cursor images
> before we destroy the display.
>
> Signed-off-by: Daniel Stone <dani...@collabora.com>
>

Yep, fixes the crash for me.

Reviewed-by: Dima Ryazanov <d...@gmail.com>

---
>  libweston/compositor-wayland.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libweston/compositor-wayland.c b/libweston/compositor-
> wayland.c
> index d9cbde5..aa69c68 100644
> --- a/libweston/compositor-wayland.c
> +++ b/libweston/compositor-wayland.c
> @@ -2368,10 +2368,6 @@ wayland_destroy(struct weston_compositor *ec)
> if (b->parent.compositor)
> wl_compositor_destroy(b->parent.compositor);
>
> -   wl_registry_destroy(b->parent.registry);
> -   wl_display_flush(b->parent.wl_display);
> -   wl_display_disconnect(b->parent.wl_display);
> -
> if (b->theme)
> theme_destroy(b->theme);
>
> @@ -2380,6 +2376,10 @@ wayland_destroy(struct weston_compositor *ec)
>
> wl_cursor_theme_destroy(b->cursor_theme);
>
> +   wl_registry_destroy(b->parent.registry);
> +   wl_display_flush(b->parent.wl_display);
> +   wl_display_disconnect(b->parent.wl_display);
> +
> free(b);
>  }
>
> --
> 2.9.3
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 1/2] Don't prepend protocol/ to include paths

[Dima Ryazanov]

On Thu, Nov 24, 2016 at 7:32 AM, Daniel Stone <dani...@collabora.com> wrote:

> No need to add protocol/, as it's already handled by an explicit
> compiler include path.
>
> Signed-off-by: Daniel Stone <dani...@collabora.com>
>

Reviewed-by: Dima Ryazanov <d...@gmail.com>


> ---
>  libweston-desktop/xdg-shell-v5.c | 2 +-
>  libweston-desktop/xdg-shell-v6.c | 2 +-
>  libweston/input.c| 4 ++--
>  3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libweston-desktop/xdg-shell-v5.c
> b/libweston-desktop/xdg-shell-v5.c
> index 9fd3a87..08cf71e 100644
> --- a/libweston-desktop/xdg-shell-v5.c
> +++ b/libweston-desktop/xdg-shell-v5.c
> @@ -32,7 +32,7 @@
>
>  #include "compositor.h"
>  #include "zalloc.h"
> -#include "protocol/xdg-shell-unstable-v5-server-protocol.h"
> +#include "xdg-shell-unstable-v5-server-protocol.h"
>
>  #include "libweston-desktop.h"
>  #include "internal.h"
> diff --git a/libweston-desktop/xdg-shell-v6.c
> b/libweston-desktop/xdg-shell-v6.c
> index edd1dc4..7d0bd8e 100644
> --- a/libweston-desktop/xdg-shell-v6.c
> +++ b/libweston-desktop/xdg-shell-v6.c
> @@ -33,7 +33,7 @@
>
>  #include "compositor.h"
>  #include "zalloc.h"
> -#include "protocol/xdg-shell-unstable-v6-server-protocol.h"
> +#include "xdg-shell-unstable-v6-server-protocol.h"
>
>  #include "libweston-desktop.h"
>  #include "internal.h"
> diff --git a/libweston/input.c b/libweston/input.c
> index 471c65e..4fedc55 100644
> --- a/libweston/input.c
> +++ b/libweston/input.c
> @@ -39,8 +39,8 @@
>  #include "shared/helpers.h"
>  #include "shared/os-compatibility.h"
>  #include "compositor.h"
> -#include "protocol/relative-pointer-unstable-v1-server-protocol.h"
> -#include "protocol/pointer-constraints-unstable-v1-server-protocol.h"
> +#include "relative-pointer-unstable-v1-server-protocol.h"
> +#include "pointer-constraints-unstable-v1-server-protocol.h"
>
>  enum pointer_constraint_type {
> POINTER_CONSTRAINT_TYPE_LOCK,
> --
> 2.9.3
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v2] compositor-wayland: Fix a use after free

[Dima Ryazanov]

Oh, good catch; just reviewed it. Thanks!

On Mon, Nov 28, 2016 at 10:20 AM, Daniel Stone <dan...@fooishbar.org> wrote:

> Hi Dima,
>
> On 24 November 2016 at 13:13, Dima Ryazanov <d...@gmail.com> wrote:
> > When a window is being closed, the frame_done callback often runs after
> > the output is already destroyed, i.e:
> >
> >   wayland_output_start_repaint_loop
> >   input_handle_button
> > wayland_output_destroy
> >   frame_done
> >
> > To fix this, destroy the callback before destroying the output.
> >
> > (Also, fix the type of output in frame_done: it's passed in
> > a wayland_output, not a weston_output.)
>
> I accidentally pushed this, when I meant to push the gl-renderer patch
> instead. Turns out this breaks Pixman; I've sent a follow-up patch
> which fixes this. Can you please review it when you can?
>
> Cheers,
> Daniel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] compositor-wayland: Set frame callback for Pixman

[Dima Ryazanov]

Yep, fixes the crash, thanks!

Reviewed-by: Dima Ryazanov <d...@gmail.com>

On Mon, Nov 28, 2016 at 8:06 AM, Daniel Stone <dani...@collabora.com> wrote:

> Fixing 89c2f637b9, also set the output's frame_cb for the Pixman
> renderer, not just GL. Fixes a segfault when using compositor-wayland
> with --use-pixman.
>
> Signed-off-by: Daniel Stone <dani...@collabora.com>
> Cc: Dima Ryazanov <d...@gmail.com>
> ---
>  libweston/compositor-wayland.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/libweston/compositor-wayland.c b/libweston/compositor-
> wayland.c
> index 7c814c8..d1e387d 100644
> --- a/libweston/compositor-wayland.c
> +++ b/libweston/compositor-wayland.c
> @@ -593,7 +593,6 @@ wayland_output_repaint_pixman(struct weston_output
> *output_base,
> struct wayland_output *output = to_wayland_output(output_base);
> struct wayland_backend *b =
> to_wayland_backend(output->base.compositor);
> -   struct wl_callback *callback;
> struct wayland_shm_buffer *sb;
>
> if (output->frame) {
> @@ -613,8 +612,8 @@ wayland_output_repaint_pixman(struct weston_output
> *output_base,
>
> wayland_shm_buffer_attach(sb);
>
> -   callback = wl_surface_frame(output->parent.surface);
> -   wl_callback_add_listener(callback, _listener, output);
> +   output->frame_cb = wl_surface_frame(output->parent.surface);
> +   wl_callback_add_listener(output->frame_cb, _listener,
> output);
> wl_surface_commit(output->parent.surface);
> wl_display_flush(b->parent.wl_display);
>
> --
> 2.9.3
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] compositor-wayland: Fix a use after free

[Dima Ryazanov]

Oh damn, I was looking for an API to cancel a callback and couldn't find
anything; didn't realize all I needed to do is destroy it. That makes it so
much simpler. I'll send out a follow-up patch.

Thanks!


On Thu, Nov 24, 2016 at 4:05 AM, Daniel Stone <dan...@fooishbar.org> wrote:

> Hi Dima,
>
> On 24 November 2016 at 06:07, Dima Ryazanov <d...@gmail.com> wrote:
> > When a window is being closed, the frame_done callback often runs after
> > the output is already destroyed, i.e:
> >
> >   wayland_output_start_repaint_loop
> >   input_handle_button
> > wayland_output_destroy
> >   frame_done
> >
> > To fix this, destroy the output from an idle handler (same as
> compositor-x11),
> > and also stop creating new frame_done callbacks.
>
> Hm. The reason for moving destroy to an idle handler in X11, is that
> handle_event may be called 'in the middle of repaint'. I suspect - and
> Derek, please correct me if I'm wrong - that this was because we may
> start the X11 repaint loop, send a request, await a reply, and whilst
> waiting for that reply, receive a DELETE_WINDOW event which causes us
> to delete. Which would be bad.
>
> If that's right, then it's a different root cause. We'll never
> dispatch any Wayland events during repaint; we don't do so ourselves,
> and the only thing that could cause to is EGL, which must only be
> dispatching on its own separate event queue.
>
> So, if the root cause is the frame callback arriving after destroy:
> why not just destroy the frame callback, so we never receive it, and
> can destroy immediately?
>
> Cheers,
> Daniel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] gl-renderer: Fix an invalid write when closing a Weston window

[Dima Ryazanov]

Hi Daniel,

Forgot to mention: this only happens when using the wayland backend, not
x11. It's triggered by the next call to eglMakeCurrent (when the remaining
window is repainted), so it might not happen immediately, either. I'm using
an Intel graphics card and Mesa 12.0.3.

I actually saw the comment in gl_renderer_destroy and searched for Mesa
bugs, but found this email:
https://lists.freedesktop.org/archives/wayland-devel/2013-October/011622.html
"[...] An EGLSurface is current for a context from eglMakeCurrent up until
eglMakeCurrent is called for the conetxte with another surface or the
context is destroyed.  The wl_egl_surface (the native window object) has to
be available (can not be destroyed) for the entire time the EGLSurface
exists."
(Though it's from 2013, so maybe things have changed since.)

There was also a similar fix for the simple-egl client a while ago:
https://lists.freedesktop.org/archives/wayland-devel/2013-April/008718.html

On Thu, Nov 24, 2016 at 3:51 AM, Daniel Stone <dan...@fooishbar.org> wrote:

> Hi Dima,
>
> On 24 November 2016 at 02:41, Dima Ryazanov <d...@gmail.com> wrote:
> > Call eglMakeCurrent before destroying the native EGL window, similar to
> what
> > other sample clients are already doing.
>
> This doesn't show as an error here, with your suggested reproduction
> instructions. From eglDestroySurface:
> 'If the EGL surface surface is not current to any thread,
> eglDestroySurface destroys it immediately. Otherwise, surface is
> destroyed when it becomes not current to any thread.'
>
> Which GL stack are you using? The comment above the no-surface
> MakeCurrent in gl_renderer_destroy() is probably pretty telling, that
> Mesa once had a bug.
>
> Regardless of this, I am inclined to apply it to match the others,
> even just so we can be sure that the destroy takes effect immediately.
>
> Cheers,
> Daniel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] compositor-wayland: Fix a use after free

[Dima Ryazanov]

When a window is being closed, the frame_done callback often runs after
the output is already destroyed, i.e:

  wayland_output_start_repaint_loop
  input_handle_button
wayland_output_destroy
  frame_done

To fix this, destroy the output from an idle handler (same as compositor-x11),
and also stop creating new frame_done callbacks.

Signed-off-by: Dima Ryazanov <d...@gmail.com>
---
 libweston/compositor-wayland.c | 59 +++---
 1 file changed, 50 insertions(+), 9 deletions(-)

diff --git a/libweston/compositor-wayland.c b/libweston/compositor-wayland.c
index d9cbde5..fc5daf4 100644
--- a/libweston/compositor-wayland.c
+++ b/libweston/compositor-wayland.c
@@ -128,6 +128,13 @@ struct wayland_output {
 
struct weston_mode mode;
uint32_t scale;
+
+   bool destroy_pending;
+};
+
+struct output_destroy_data {
+   struct wayland_backend *backend;
+   struct wayland_output *output;
 };
 
 struct wayland_parent_output {
@@ -460,6 +467,9 @@ wayland_output_start_repaint_loop(struct weston_output 
*output_base)
to_wayland_backend(output->base.compositor);
struct wl_callback *callback;
 
+   if (output->destroy_pending)
+   return;
+
/* If this is the initial frame, we need to attach a buffer so that
 * the compositor can map the surface and include it in its render
 * loop. If the surface doesn't end up in the render loop, the frame
@@ -485,6 +495,9 @@ wayland_output_repaint_gl(struct weston_output *output_base,
struct weston_compositor *ec = output->base.compositor;
struct wl_callback *callback;
 
+   if (output->destroy_pending)
+   return 0;
+
callback = wl_surface_frame(output->parent.surface);
wl_callback_add_listener(callback, _listener, output);
 
@@ -696,6 +709,41 @@ wayland_output_destroy(struct weston_output *base)
free(output);
 }
 
+static void
+output_destroy_cb(void *data)
+{
+   struct output_destroy_data *dd = data;
+
+   assert(dd->output->destroy_pending);
+
+   wayland_output_destroy(>output->base);
+   if (wl_list_empty(>backend->compositor->output_list))
+   weston_compositor_exit(dd->backend->compositor);
+
+   free(dd);
+}
+
+static void
+handle_window_closed(struct wayland_backend *backend, struct wayland_output 
*output)
+{
+   struct wl_event_loop *loop;
+   struct output_destroy_data *data;
+
+   assert(!output->destroy_pending);
+
+   data = malloc(sizeof *data);
+   if (!data)
+   return;  /* Not much we can do here. */
+
+   data->backend = backend;
+   data->output = output;
+
+   loop = wl_display_get_event_loop(backend->compositor->wl_display);
+   wl_event_loop_add_idle(loop, output_destroy_cb, data);
+
+   output->destroy_pending = true;
+}
+
 static const struct wl_shell_surface_listener shell_surface_listener;
 
 static int
@@ -1600,13 +1648,9 @@ input_handle_button(void *data, struct wl_pointer 
*pointer,
}
 
if (frame_status(input->output->frame) & FRAME_STATUS_CLOSE) {
-   wayland_output_destroy(>output->base);
+   handle_window_closed(input->backend, input->output);
input->output = NULL;
input->keyboard_focus = NULL;
-
-   if 
(wl_list_empty(>backend->compositor->output_list))
-   
weston_compositor_exit(input->backend->compositor);
-
return;
}
 
@@ -1964,12 +2008,9 @@ input_handle_touch_up(void *data, struct wl_touch 
*wl_touch,
frame_touch_up(output->frame, input, id);
 
if (frame_status(output->frame) & FRAME_STATUS_CLOSE) {
-   wayland_output_destroy(>base);
+   handle_window_closed(input->backend, output);
input->touch_focus = NULL;
input->keyboard_focus = NULL;
-   if 
(wl_list_empty(>backend->compositor->output_list))
-   
weston_compositor_exit(input->backend->compositor);
-
return;
}
if (frame_status(output->frame) & FRAME_STATUS_REPAINT)
-- 
2.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] gl-renderer: Fix an invalid write when closing a Weston window

[Dima Ryazanov]

To repro, run "valgrind weston --output-count=2", and close one of the
windows. (When you close the last window, there are even more errors, so
this particular one isn't as noticeable.)

On Wed, Nov 23, 2016 at 6:41 PM, Dima Ryazanov <d...@gmail.com> wrote:

> Call eglMakeCurrent before destroying the native EGL window, similar to
> what
> other sample clients are already doing.
>
> Signed-off-by: Dima Ryazanov <d...@gmail.com>
> ---
>  libweston/gl-renderer.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
> index d08bfd0..c6091af 100644
> --- a/libweston/gl-renderer.c
> +++ b/libweston/gl-renderer.c
> @@ -2760,6 +2760,10 @@ gl_renderer_output_destroy(struct weston_output
> *output)
> for (i = 0; i < 2; i++)
> pixman_region32_fini(>buffer_damage[i]);
>
> +   eglMakeCurrent(gr->egl_display,
> +  EGL_NO_SURFACE, EGL_NO_SURFACE,
> +  EGL_NO_CONTEXT);
> +
> weston_platform_destroy_egl_surface(gr->egl_display,
> go->egl_surface);
>
> free(go);
> --
> 2.9.3
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] gl-renderer: Fix an invalid write when closing a Weston window

[Dima Ryazanov]

Call eglMakeCurrent before destroying the native EGL window, similar to what
other sample clients are already doing.

Signed-off-by: Dima Ryazanov <d...@gmail.com>
---
 libweston/gl-renderer.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index d08bfd0..c6091af 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -2760,6 +2760,10 @@ gl_renderer_output_destroy(struct weston_output *output)
for (i = 0; i < 2; i++)
pixman_region32_fini(>buffer_damage[i]);
 
+   eglMakeCurrent(gr->egl_display,
+  EGL_NO_SURFACE, EGL_NO_SURFACE,
+  EGL_NO_CONTEXT);
+
weston_platform_destroy_egl_surface(gr->egl_display, go->egl_surface);
 
free(go);
-- 
2.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] Get rid of the window_create_menu function

[Dima Ryazanov]

It's currently unused, and there's actually no way to use it correctly.

The caller cannot free the menu that was created:
- the function only returns the window, not the menu
- there's no public API to destroy a menu object

Signed-off-by: Dima Ryazanov <d...@gmail.com>
---
 clients/window.c | 15 ---
 clients/window.h |  5 -
 2 files changed, 20 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index 84d585e..c3c8c9e 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -5470,21 +5470,6 @@ create_menu(struct display *display,
return menu;
 }
 
-struct window *
-window_create_menu(struct display *display,
-  struct input *input, uint32_t time,
-  menu_func_t func, const char **entries, int count,
-  void *user_data)
-{
-   struct menu *menu;
-   menu = create_menu(display, input, time, func, entries, count, 
user_data);
-
-   if (menu == NULL)
-   return NULL;
-
-   return menu->window;
-}
-
 static struct zxdg_positioner_v6 *
 create_simple_positioner(struct display *display,
 int x, int y)
diff --git a/clients/window.h b/clients/window.h
index 1ad3b4f..1ec9eac 100644
--- a/clients/window.h
+++ b/clients/window.h
@@ -322,11 +322,6 @@ window_has_focus(struct window *window);
 
 typedef void (*menu_func_t)(void *data, struct input *input, int index);
 
-struct window *
-window_create_menu(struct display *display,
-  struct input *input, uint32_t time,
-  menu_func_t func, const char **entries, int count,
-  void *user_data);
 void
 window_show_menu(struct display *display,
 struct input *input, uint32_t time, struct window *parent,
-- 
2.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Implementing show_window_menu in Weston

[Dima Ryazanov]

Got it, thanks Jonas!

On Wed, Nov 9, 2016 at 8:56 PM, Jonas Ådahl <jad...@gmail.com> wrote:

> On Wed, Nov 09, 2016 at 03:21:30PM -0800, Dima Ryazanov wrote:
> > Hi,
> >
> > I'd like to take a shot at implementing window menus (from xdg-shell) in
> > Weston - but I don't have a good understanding of how the compositor,
> > shell, etc. interact, so wanted to ask about it first.
> >
> > Looks like the entry point for it would be the "show_window_menu" member
> of
> > "shell_desktop_api" in desktop-shell/shell.c. Now, this may be a stupid
> > question, but should the menu be implemented in the compositor or in the
> > shell client?
>
> The drawing should be done by the shell client. In the reference shell
> implementation in weston, the compositor never does any drawing (well,
> except for Xwayland window frame I suppose), and that should continue to
> be the case.
>
> >
> > I feel like it's the compositor's job, but I can't find any examples of
> > drawing things or handling input in the compositor itself. If I do it in
> > the desktop shell, then I could use the existing popup menu code in
> > clients/window.c - but would have to add a bunch of requests to the
> desktop
> > shell protocol just to display the menu and handle the menu items. What's
> > the correct approach?
>
> Yes, add new requests/events to the weston desktop shell protocol.
> It's a private protocol so there is no need to care about any backward
> compatibility.
>
>
> Jonas
>
> >
> > Thanks!
>
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Implementing show_window_menu in Weston

[Dima Ryazanov]

Hi,

I'd like to take a shot at implementing window menus (from xdg-shell) in
Weston - but I don't have a good understanding of how the compositor,
shell, etc. interact, so wanted to ask about it first.

Looks like the entry point for it would be the "show_window_menu" member of
"shell_desktop_api" in desktop-shell/shell.c. Now, this may be a stupid
question, but should the menu be implemented in the compositor or in the
shell client?

I feel like it's the compositor's job, but I can't find any examples of
drawing things or handling input in the compositor itself. If I do it in
the desktop shell, then I could use the existing popup menu code in
clients/window.c - but would have to add a bunch of requests to the desktop
shell protocol just to display the menu and handle the menu items. What's
the correct approach?

Thanks!
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] Ignore the OSC code for desktop notifications

[Dima Ryazanov]

In Fedora, bash is configured to display a desktop notification when a command
finishes (and the terminal is not focused). weston-terminal complains about it;
let's silence it.

Signed-off-by: Dima Ryazanov <d...@gmail.com>
---
 clients/terminal.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/clients/terminal.c b/clients/terminal.c
index 6257cb7..64768eb 100644
--- a/clients/terminal.c
+++ b/clients/terminal.c
@@ -1297,6 +1297,8 @@ handle_osc(struct terminal *terminal)
break;
case 7: /* shell cwd as uri */
break;
+   case 777: /* Desktop notifications */
+   break;
default:
fprintf(stderr, "Unknown OSC escape code %d, text %s\n",
code, p);
-- 
2.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] evdev: actually ignore joysticks

[Dima Ryazanov]

On Tue, Nov 1, 2016 at 6:19 PM, Peter Hutterer 
wrote:

> A joystick has ID_INPUT_JOYSTICK *and* ID_INPUT set, so we need to check
> for
> both.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=98009
>
> Signed-off-by: Peter Hutterer 
> ---
>  src/evdev.c   |  2 +-
>  test/device.c | 34 ++
>  2 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/src/evdev.c b/src/evdev.c
> index d49b391..b7396f3 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -2468,7 +2468,7 @@ evdev_configure_device(struct evdev_device *device)
>
> /* libwacom *adds* TABLET, TOUCHPAD but leaves JOYSTICK in place,
> so
>make sure we only ignore real joystick devices */
> -   if ((udev_tags & EVDEV_UDEV_TAG_JOYSTICK) == udev_tags) {
> +   if ((udev_tags & (EVDEV_UDEV_TAG_INPUT|EVDEV_UDEV_TAG_JOYSTICK))
> == udev_tags) {
>

Shouldn't this just be "udev_tags == EVDEV_UDEV_TAG_INPUT|EVDEV_
UDEV_TAG_JOYSTICK"?

Otherwise, the check will succeed even if udev_tags is just
EVDEV_UDEV_TAG_INPUT. (Assuming such devices exist, that is.)


> log_info(libinput,
>  "input device '%s', %s is a joystick, ignoring\n",
>  device->devname, devnode);
> diff --git a/test/device.c b/test/device.c
> index 4ed12d9..f44a988 100644
> --- a/test/device.c
> +++ b/test/device.c
> @@ -1058,6 +1058,39 @@ START_TEST(abs_mt_device_missing_res)
>  }
>  END_TEST
>
> +START_TEST(ignore_joystick)
> +{
> +   struct libinput *li;
> +   struct libevdev_uinput *uinput;
> +   struct libinput_device *device;
> +   struct input_absinfo absinfo[] = {
> +   { ABS_X, 0, 10, 0, 0, 10 },
> +   { ABS_Y, 0, 10, 0, 0, 10 },
> +   { ABS_RX, 0, 10, 0, 0, 10 },
> +   { ABS_RY, 0, 10, 0, 0, 10 },
> +   { ABS_THROTTLE, 0, 2, 0, 0, 0 },
> +   { ABS_RUDDER, 0, 255, 0, 0, 0 },
> +   { -1, -1, -1, -1, -1, -1 }
> +   };
> +
> +   li = litest_create_context();
> +   litest_disable_log_handler(li);
> +   litest_drain_events(li);
> +
> +   uinput = litest_create_uinput_abs_device("joystick test device",
> NULL,
> +absinfo,
> +EV_KEY, BTN_TRIGGER,
> +EV_KEY, BTN_A,
> +-1);
> +   device = libinput_path_add_device(li,
> + libevdev_uinput_get_devnode(
> uinput));
> +   litest_assert_ptr_null(device);
> +   libevdev_uinput_destroy(uinput);
> +   litest_restore_log_handler(li);
> +   libinput_unref(li);
> +}
> +END_TEST
> +
>  START_TEST(device_wheel_only)
>  {
> struct litest_device *dev = litest_current_device();
> @@ -1464,6 +1497,7 @@ litest_setup_tests_device(void)
> litest_add_ranged_no_device("device:invalid devices",
> abs_mt_device_no_range, _mt_range);
> litest_add_no_device("device:invalid devices",
> abs_device_missing_res);
> litest_add_no_device("device:invalid devices",
> abs_mt_device_missing_res);
> +   litest_add_no_device("device:invalid devices", ignore_joystick);
>
> litest_add("device:wheel", device_wheel_only, LITEST_WHEEL,
> LITEST_RELATIVE|LITEST_ABSOLUTE|LITEST_TABLET);
> litest_add_no_device("device:accelerometer",
> device_accelerometer);
> --
> 2.9.3
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] weston-launch: Protect KDGKBMODE K_OFF ioctl by KERNEL_VERSION check

[Dima Ryazanov]

The kernel version used to build Weston isn't necessarily the same as the
version that will be used to run it. Weston should already work fine on
older versions: the second ioctl will return an error - but it's ok as long
as the first one succeeds.

Also, a compile-time check would prevent Weston built on an old kernel from
taking advantage of new features when running on a new kernel.


On Tue, Sep 27, 2016 at 9:37 AM, Krzysztof Konopko  wrote:

> From: Tomasz SZKUTKOWSKI 
>
> This patch disables unsupported ioctl `KDGKBMODE K_OFF` command if Weston
> is built against kernel older than 2.6.39, as this ioctl has been
> introduced in 2.6.39 kernel version.
>
> No functional changes have been observed by disabling this ioctl.
>
> Signed-off-by: Tomasz SZKUTKOWSKI 
> Signed-off-by: Krzysztof Konopko 
> ---
>  libweston/launcher-direct.c | 5 +
>  libweston/weston-launch.c   | 5 +
>  2 files changed, 10 insertions(+)
>
> diff --git a/libweston/launcher-direct.c b/libweston/launcher-direct.c
> index 29d9c28..34fe5cd 100644
> --- a/libweston/launcher-direct.c
> +++ b/libweston/launcher-direct.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "launcher-impl.h"
>
> @@ -157,8 +158,12 @@ setup_tty(struct launcher_direct *launcher, int tty)
> goto err_close;
> }
>
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39)
> if (ioctl(launcher->tty, KDSKBMUTE, 1) &&
> ioctl(launcher->tty, KDSKBMODE, K_OFF)) {
> +#else
> +   if (ioctl(launcher->tty, KDSKBMUTE, 1)) {
> +#endif
> weston_log("failed to set K_OFF keyboard mode: %m\n");
> goto err_close;
> }
> diff --git a/libweston/weston-launch.c b/libweston/weston-launch.c
> index 140fde1..74b80dd 100644
> --- a/libweston/weston-launch.c
> +++ b/libweston/weston-launch.c
> @@ -49,6 +49,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -561,8 +562,12 @@ setup_tty(struct weston_launch *wl, const char *tty)
> if (ioctl(wl->tty, KDGKBMODE, >kb_mode))
> error(1, errno, "failed to get current keyboard mode:
> %m\n");
>
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39)
> if (ioctl(wl->tty, KDSKBMUTE, 1) &&
> ioctl(wl->tty, KDSKBMODE, K_OFF))
> +#else
> +   if (ioctl(wl->tty, KDSKBMUTE, 1))
> +#endif
> error(1, errno, "failed to set K_OFF keyboard mode: %m\n");
>
> if (ioctl(wl->tty, KDSETMODE, KD_GRAPHICS))
> --
> 2.1.4
>
> This transmission contains information that may be confidential and
> contain personal views which are not necessarily those of YouView TV Ltd.
> YouView TV Ltd (Co No:7308805) is a limited liability company registered in
> England and Wales with its registered address at YouView TV Ltd, 3rd Floor,
> 10 Lower Thames Street, London, EC3R 6YT. For details see our web site at
> http://www.youview.com
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland v2 4/4] array-test: Include wayland-util.h and simplify init test

[Dima Ryazanov]

I think I actually know the point of the test.

It tries to verify that size, alloc, and data were initialized to 0, rather
than left uninitialized - but the difficulty is that uninitialized memory
is often already filled with 0s. So the test repeats the process a whole
bunch of times, hoping to eventually catch non-0 uninitialized memory.

(That doesn't mean it's a good way to test it, though, so I have nothing
against removing it. Something like valgrind is probably better.)

On Tue, Sep 27, 2016 at 8:03 PM, Yong Bakos  wrote:

> From: Yong Bakos 
>
> Include wayland-util.h in addition to wayland-private.h, to be more
> explicit
> about where wl_array is defined.
>
> Remove the useless repeated testing of wl_array_init, because if it fails
> once
> out of thousands of iterations we're all doomed anyway.
>
> Signed-off-by: Yong Bakos 
> Reviewed-by: Eric Engestrom 
> Reviewed-by: Pekka Paalanen 
> ---
> v2: Add empty line (pq)
>
>  tests/array-test.c | 18 ++
>  1 file changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/tests/array-test.c b/tests/array-test.c
> index b0de8e6..ed6fbfb 100644
> --- a/tests/array-test.c
> +++ b/tests/array-test.c
> @@ -25,24 +25,18 @@
>
>  #include 
>  #include 
> +#include "wayland-util.h"
>  #include "wayland-private.h"
>  #include "test-runner.h"
>
>  TEST(array_init)
>  {
> -   const int iterations = 4122; /* this is arbitrary */
> -   int i;
> -
> -   /* Init array an arbitray amount of times and verify the
> -* defaults are sensible. */
> +   struct wl_array array;
>
> -   for (i = 0; i < iterations; i++) {
> -   struct wl_array array;
> -   wl_array_init();
> -   assert(array.size == 0);
> -   assert(array.alloc == 0);
> -   assert(array.data == 0);
> -   }
> +   wl_array_init();
> +   assert(array.size == 0);
> +   assert(array.alloc == 0);
> +   assert(array.data == 0);
>  }
>
>  TEST(array_release)
> --
> 2.7.2
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] Revert client: require WAYLAND_DISPLAY to be set

[Dima Ryazanov]

All of these arguments makes sense, so I guess I agree with reverting this
change. I didn't know about the goal of reducing the number of environment
variables. Also, the fact that wayland displays are per user makes it
different from the X11 displays. Sorry for all the trouble!

On Tue, Aug 18, 2015 at 12:34 AM, Sjoerd Simons 
sjoerd.sim...@collabora.co.uk wrote:

 On Mon, 2015-08-17 at 09:58 -0700, Bill Spitzak wrote:
  On Mon, Aug 17, 2015 at 7:48 AM, Ray Strode halfl...@gmail.com
  wrote:
 
   Hi,
  
This reverts commit fb7e13021730d0a5516ecbd3712ea4235e05d24d.
  
   thanks, you've got my vote.
  
   Acked-by: Ray Strode rstr...@redhat.com
  
   --Ray
 
 
  Seems right to me question about the method of nesting Wayland in X
  and X
  in wayland;
 
   The original problem of running Weston in a window in an existing
   GNOME
   X11 session and getting applications unintentionally launched into
   Weston can be circumvented by letting Weston use a non-default
   socket
   name, leaving wayland-0 unused.
 
  If Wayland is already running and using wayland-0 this would prevent
  these
  programs from using the X11 api. For instance if you wished to test
  the X11
  api inside a Wayland session.

 Not really it just means you require a way to override the order in
 which they try their display backends (which e.g. for Gtk+ is
 possible). As Ray previously mentioned, keeping environment variables
 for corner cases is entirely fine.

  Would it make sense that if DISPLAY is set and WAYLAND_DISPLAY is not
  set,
  that a program capable of doing both should prefer the X11 api? This
  would
  mean that I could force use of the X11 api by unsetting
  WAYLAND_DISPLAY.

 That seems rather fragile (and really up to the toolkit/program to
 implement, wayland can't know if the program supports X11).

  This will require changes to the client (unless the wayland connect  was
  changed to fail in this case, which I suspect is not a good idea)
  which
  probably explains why the idea of renaming the socket was suggested.
 
  As for the patch, I agree. The Foundry software would check if
  DISPLAY was
  not set, and set it directly to :0, so that X would work always (it
  did
  not open the display by name because it wanted to fix child programs
  as
  well). This was commercial software and this was demanded by qc. So
  effectively they wanted X11 to work without an environment variable.

 the problem with DISPLAY is that it's not namespaced per user, so if
 you have two users logged in on an X graphical session one will have
  e.g. DISPLAY=:0 the other DISPLAY=:1. Because of that defaulting to :0
 on X isn't a great idea on multi-user systems.

 However for wayland, the sockets are namespaced per user as they reside
 in their respective XDG_RUNTIME_DIR, which means two people can start a
 graphical session and both use wayland-0 for their compositor just
 fine.

 --
 Sjoerd Simons sjoerd.sim...@collabora.co.uk
 Collabora Ltd.


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

[Dima Ryazanov]

So, it seems like pretty much everyone agrees with this change. Could we
actually get it in for the 1.9 release?

On Thu, Aug 13, 2015 at 4:47 AM, Ryo Munakata ryomnk...@gmail.com wrote:

 On Wed, 12 Aug 2015 19:34:31 -0700
 Dima Ryazanov d...@gmail.com wrote:

 Hi Dima.

 Reviewed-by: Ryo Munakata ryomnk...@gmail.com

 Thanks.

  Although defaulting to wayland-0 seems convenient, it has an undesirable
  side effect: clients may unintentionally connect to the wrong compositor.
  Generally, it's safer to fail instead. Here's a real example:
 
  In Fedora 22, Gtk+ prefers Wayland over X11, though the default session
 is still
  a normal X11 Gnome session. When you launch a Gtk+ app, it will try
 Wayland,
  fail, then try X11, and succesfully start up. That works fine.
 
  Now suppose you launch Weston while running the Gnome session. Suddenly,
 all
  of the Gtk+ apps launched from Gnome will show up inside Weston instead.
  That's unexpected. There's also no good way to prevent that from
 happening
  (other than perhaps setting WAYLAND_DISPLAY to an invalid value when
 launching
  an app).
 
  Not using wayland-0 as the default will solve that problem: an app
 launched
  from the X11 Gnome session will use the X11 backend regardless of whether
  there's a wayland compositor running at the same time.
 
  Everything else should work as before. The compositor already sets
  the WAYLAND_DISPLAY when starting the session, so the lack of the
 default value
  should not make a difference to the user.
 
  Signed-off-by: Dima Ryazanov d...@gmail.com
  Acked-by: Pekka Paalanen ppaala...@gmail.com
  Acked-by: Giulio Camuffo giuliocamu...@gmail.com
  Acked-by: Daniel Stone dan...@fooishbar.org
  Acked-by: Jasper St. Pierre jstpie...@mecheye.net
  ---
   doc/man/wl_display_connect.xml|  5 ++---
   doc/publican/sources/Protocol.xml |  8 
   src/wayland-client.c  | 10 ++
   src/wayland-server.c  |  6 +++---
   4 files changed, 15 insertions(+), 14 deletions(-)
 
  diff --git a/doc/man/wl_display_connect.xml
 b/doc/man/wl_display_connect.xml
  index 7e6e05c..ded3cbd 100644
  --- a/doc/man/wl_display_connect.xml
  +++ b/doc/man/wl_display_connect.xml
  @@ -57,9 +57,8 @@
 that was previously opened by a Wayland server. The server
 socket must
 be placed in envarXDG_RUNTIME_DIR/envar for this function
 to
 find it. The varnamename/varname argument specifies the
 name of
  -  the socket or constantNULL/constant to use the default
 (which is
  -  constantwayland-0/constant). The environment variable
  -  envarWAYLAND_DISPLAY/envar replaces the default value. If
  +  the socket or constantNULL/constant to use the default
  +  (which is the value of envarWAYLAND_DISPLAY/envar). If
 envarWAYLAND_SOCKET/envar is set, this function behaves
 like
 functionwl_display_connect_to_fd/function with the
 file-descriptor
 number taken from the environment variable./para
  diff --git a/doc/publican/sources/Protocol.xml
 b/doc/publican/sources/Protocol.xml
  index 477063b..9464953 100644
  --- a/doc/publican/sources/Protocol.xml
  +++ b/doc/publican/sources/Protocol.xml
  @@ -60,10 +60,10 @@
   titleWire Format/title
   para
 The protocol is sent over a UNIX domain stream socket, where the
 endpoint
  -  usually is named systemitem
 class=servicewayland-0/systemitem
  -  (although it can be changed via
 emphasisWAYLAND_DISPLAY/emphasis
  -  in the environment).  The protocol is message-based.  A
  -  message sent by a client to the server is called request.  A
 message
  +  name is determined by the emphasisWAYLAND_DISPLAY/emphasis
  +  environment variable.  Its value will usually be
  +  systemitem class=servicewayland-0/systemitem.  The protocol
 is message-based.
  +  A message sent by a client to the server is called request.  A
 message
 from the server to a client is called event.  Every message is
 structured as 32-bit words, values are represented in the host's
 byte-order.
  diff --git a/src/wayland-client.c b/src/wayland-client.c
  index 09c594a..ffbca4b 100644
  --- a/src/wayland-client.c
  +++ b/src/wayland-client.c
  @@ -764,8 +764,11 @@ connect_to_socket(const char *name)
 
if (name == NULL)
name = getenv(WAYLAND_DISPLAY);
  - if (name == NULL)
  - name = wayland-0;
  + if (name == NULL) {
  + wl_log(error: WAYLAND_DISPLAY not set in the
 environment.\n);
  + errno = ENOENT;
  + return -1;
  + }
 
fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
if (fd  0)
  @@ -869,8 +872,7 @@ wl_display_connect_to_fd(int fd)
* \return A \ref wl_display object or \c NULL on failure
*
* Connect to the Wayland display named \c name. If \c name is \c NULL,
  - * its value will be replaced

Re: [PATCH wayland] Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

[Dima Ryazanov]

Oh, you're right, I didn't realize that's what that code was doing.

Thanks!


On Fri, Aug 14, 2015 at 12:20 AM, Pekka Paalanen ppaala...@gmail.com
wrote:

 On Wed, 12 Aug 2015 19:34:31 -0700
 Dima Ryazanov d...@gmail.com wrote:

  Although defaulting to wayland-0 seems convenient, it has an undesirable
  side effect: clients may unintentionally connect to the wrong compositor.
  Generally, it's safer to fail instead. Here's a real example:
 
  In Fedora 22, Gtk+ prefers Wayland over X11, though the default session
 is still
  a normal X11 Gnome session. When you launch a Gtk+ app, it will try
 Wayland,
  fail, then try X11, and succesfully start up. That works fine.
 
  Now suppose you launch Weston while running the Gnome session. Suddenly,
 all
  of the Gtk+ apps launched from Gnome will show up inside Weston instead.
  That's unexpected. There's also no good way to prevent that from
 happening
  (other than perhaps setting WAYLAND_DISPLAY to an invalid value when
 launching
  an app).
 
  Not using wayland-0 as the default will solve that problem: an app
 launched
  from the X11 Gnome session will use the X11 backend regardless of whether
  there's a wayland compositor running at the same time.
 
  Everything else should work as before. The compositor already sets
  the WAYLAND_DISPLAY when starting the session, so the lack of the
 default value
  should not make a difference to the user.
 
  Signed-off-by: Dima Ryazanov d...@gmail.com
  Acked-by: Pekka Paalanen ppaala...@gmail.com
  Acked-by: Giulio Camuffo giuliocamu...@gmail.com
  Acked-by: Daniel Stone dan...@fooishbar.org
  Acked-by: Jasper St. Pierre jstpie...@mecheye.net
  ---
   doc/man/wl_display_connect.xml|  5 ++---
   doc/publican/sources/Protocol.xml |  8 
   src/wayland-client.c  | 10 ++
   src/wayland-server.c  |  6 +++---
   4 files changed, 15 insertions(+), 14 deletions(-)
 
  diff --git a/doc/man/wl_display_connect.xml
 b/doc/man/wl_display_connect.xml
  index 7e6e05c..ded3cbd 100644
  --- a/doc/man/wl_display_connect.xml
  +++ b/doc/man/wl_display_connect.xml
  @@ -57,9 +57,8 @@
 that was previously opened by a Wayland server. The server
 socket must
 be placed in envarXDG_RUNTIME_DIR/envar for this function
 to
 find it. The varnamename/varname argument specifies the
 name of
  -  the socket or constantNULL/constant to use the default
 (which is
  -  constantwayland-0/constant). The environment variable
  -  envarWAYLAND_DISPLAY/envar replaces the default value. If
  +  the socket or constantNULL/constant to use the default
  +  (which is the value of envarWAYLAND_DISPLAY/envar). If
 envarWAYLAND_SOCKET/envar is set, this function behaves
 like
 functionwl_display_connect_to_fd/function with the
 file-descriptor
 number taken from the environment variable./para
  diff --git a/doc/publican/sources/Protocol.xml
 b/doc/publican/sources/Protocol.xml
  index 477063b..9464953 100644
  --- a/doc/publican/sources/Protocol.xml
  +++ b/doc/publican/sources/Protocol.xml
  @@ -60,10 +60,10 @@
   titleWire Format/title
   para
 The protocol is sent over a UNIX domain stream socket, where the
 endpoint
  -  usually is named systemitem
 class=servicewayland-0/systemitem
  -  (although it can be changed via
 emphasisWAYLAND_DISPLAY/emphasis
  -  in the environment).  The protocol is message-based.  A
  -  message sent by a client to the server is called request.  A
 message
  +  name is determined by the emphasisWAYLAND_DISPLAY/emphasis
  +  environment variable.  Its value will usually be
  +  systemitem class=servicewayland-0/systemitem.  The protocol
 is message-based.
  +  A message sent by a client to the server is called request.  A
 message
 from the server to a client is called event.  Every message is
 structured as 32-bit words, values are represented in the host's
 byte-order.
  diff --git a/src/wayland-client.c b/src/wayland-client.c
  index 09c594a..ffbca4b 100644
  --- a/src/wayland-client.c
  +++ b/src/wayland-client.c
  @@ -764,8 +764,11 @@ connect_to_socket(const char *name)
 
if (name == NULL)
name = getenv(WAYLAND_DISPLAY);
  - if (name == NULL)
  - name = wayland-0;
  + if (name == NULL) {
  + wl_log(error: WAYLAND_DISPLAY not set in the
 environment.\n);
  + errno = ENOENT;
  + return -1;
  + }
 
fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
if (fd  0)
  @@ -869,8 +872,7 @@ wl_display_connect_to_fd(int fd)
* \return A \ref wl_display object or \c NULL on failure
*
* Connect to the Wayland display named \c name. If \c name is \c NULL,
  - * its value will be replaced with the WAYLAND_DISPLAY environment
  - * variable if it is set, otherwise display wayland-0 will be used.
  + * its

Re: [PATCH wayland] RFC: Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

[Dima Ryazanov]

Sounds good, will do!

On Wed, Aug 12, 2015 at 4:41 AM, Pekka Paalanen ppaala...@gmail.com wrote:

 On Mon, 25 May 2015 01:12:15 -0700
 Dima Ryazanov d...@gmail.com wrote:

  Although defaulting to wayland-0 seems convenient, it has an undesirable
  side effect: clients may unintentionally connect to the wrong compositor.
  Generally, it's safer to fail instead. Here's a real example:
 
  In Fedora 22, Gtk+ prefers Wayland over X11, though the default session
 is still
  a normal X11 Gnome session. When you launch a Gtk+ app, it will try
 Wayland,
  fail, then try X11, and succesfully start up. That works fine.
 
  Now suppose you launch Weston while running the Gnome session. Suddenly,
 all
  of the Gtk+ apps launched from Gnome will show up inside Weston instead.
  That's unexpected. There's also no good way to prevent that from
 happening
  (other than perhaps setting WAYLAND_DISPLAY to an invalid value when
 launching
  an app).
 
  Not using wayland-0 as the default will solve that problem: an app
 launched
  from the X11 Gnome session will use the X11 backend regardless of whether
  there's a wayland compositor running at the same time.
 
  Everything else should work as before. The compositor already sets
  the WAYLAND_DISPLAY when starting the session, so the lack of the
 default value
  should not make a difference to the user.
 
  Signed-off-by: Dima Ryazanov d...@gmail.com

 Hi,

 gathering the comments from the thread, it seems we have Acked-bys from:
 Pekka Paalanen ppaala...@gmail.com
 Giulio Camuffo giuliocamu...@gmail.com
 Daniel Stone dan...@fooishbar.org
 Jasper St. Pierre jstpie...@mecheye.net

 Seems like a pretty strong set. Would you like to send a non-RFC
 version of this patch?

 I think you can include also the above Acked-bys.


 Thanks,
 pq

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland] Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

[Dima Ryazanov]

Although defaulting to wayland-0 seems convenient, it has an undesirable
side effect: clients may unintentionally connect to the wrong compositor.
Generally, it's safer to fail instead. Here's a real example:

In Fedora 22, Gtk+ prefers Wayland over X11, though the default session is still
a normal X11 Gnome session. When you launch a Gtk+ app, it will try Wayland,
fail, then try X11, and succesfully start up. That works fine.

Now suppose you launch Weston while running the Gnome session. Suddenly, all
of the Gtk+ apps launched from Gnome will show up inside Weston instead.
That's unexpected. There's also no good way to prevent that from happening
(other than perhaps setting WAYLAND_DISPLAY to an invalid value when launching
an app).

Not using wayland-0 as the default will solve that problem: an app launched
from the X11 Gnome session will use the X11 backend regardless of whether
there's a wayland compositor running at the same time.

Everything else should work as before. The compositor already sets
the WAYLAND_DISPLAY when starting the session, so the lack of the default value
should not make a difference to the user.

Signed-off-by: Dima Ryazanov d...@gmail.com
Acked-by: Pekka Paalanen ppaala...@gmail.com
Acked-by: Giulio Camuffo giuliocamu...@gmail.com
Acked-by: Daniel Stone dan...@fooishbar.org
Acked-by: Jasper St. Pierre jstpie...@mecheye.net
---
 doc/man/wl_display_connect.xml|  5 ++---
 doc/publican/sources/Protocol.xml |  8 
 src/wayland-client.c  | 10 ++
 src/wayland-server.c  |  6 +++---
 4 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/doc/man/wl_display_connect.xml b/doc/man/wl_display_connect.xml
index 7e6e05c..ded3cbd 100644
--- a/doc/man/wl_display_connect.xml
+++ b/doc/man/wl_display_connect.xml
@@ -57,9 +57,8 @@
   that was previously opened by a Wayland server. The server socket 
must
   be placed in envarXDG_RUNTIME_DIR/envar for this function to
   find it. The varnamename/varname argument specifies the name of
-  the socket or constantNULL/constant to use the default (which is
-  constantwayland-0/constant). The environment variable
-  envarWAYLAND_DISPLAY/envar replaces the default value. If
+  the socket or constantNULL/constant to use the default
+  (which is the value of envarWAYLAND_DISPLAY/envar). If
   envarWAYLAND_SOCKET/envar is set, this function behaves like
   functionwl_display_connect_to_fd/function with the 
file-descriptor
   number taken from the environment variable./para
diff --git a/doc/publican/sources/Protocol.xml 
b/doc/publican/sources/Protocol.xml
index 477063b..9464953 100644
--- a/doc/publican/sources/Protocol.xml
+++ b/doc/publican/sources/Protocol.xml
@@ -60,10 +60,10 @@
 titleWire Format/title
 para
   The protocol is sent over a UNIX domain stream socket, where the endpoint
-  usually is named systemitem class=servicewayland-0/systemitem
-  (although it can be changed via emphasisWAYLAND_DISPLAY/emphasis
-  in the environment).  The protocol is message-based.  A
-  message sent by a client to the server is called request.  A message
+  name is determined by the emphasisWAYLAND_DISPLAY/emphasis
+  environment variable.  Its value will usually be
+  systemitem class=servicewayland-0/systemitem.  The protocol is 
message-based.
+  A message sent by a client to the server is called request.  A message
   from the server to a client is called event.  Every message is
   structured as 32-bit words, values are represented in the host's
   byte-order.
diff --git a/src/wayland-client.c b/src/wayland-client.c
index 09c594a..ffbca4b 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -764,8 +764,11 @@ connect_to_socket(const char *name)
 
if (name == NULL)
name = getenv(WAYLAND_DISPLAY);
-   if (name == NULL)
-   name = wayland-0;
+   if (name == NULL) {
+   wl_log(error: WAYLAND_DISPLAY not set in the environment.\n);
+   errno = ENOENT;
+   return -1;
+   }
 
fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
if (fd  0)
@@ -869,8 +872,7 @@ wl_display_connect_to_fd(int fd)
  * \return A \ref wl_display object or \c NULL on failure
  *
  * Connect to the Wayland display named \c name. If \c name is \c NULL,
- * its value will be replaced with the WAYLAND_DISPLAY environment
- * variable if it is set, otherwise display wayland-0 will be used.
+ * its value will be replaced with the WAYLAND_DISPLAY environment variable.
  *
  * \memberof wl_display
  */
diff --git a/src/wayland-server.c b/src/wayland-server.c
index 0f04f66..1ea53f9 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -1209,8 +1209,8 @@ wl_display_add_socket_auto(struct wl_display *display)
  * connect to Wayland display.
  *
  * If NULL is passed as name, then it would look

Re: [PATCH wayland] RFC: Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

[Dima Ryazanov]

Bringing this up again. What do you guys think? Does it make sense to push
this change?

On Wed, May 27, 2015 at 1:50 AM, Dima Ryazanov d...@gmail.com wrote:

 (Oops, sent too soon by accident.)

 Yep, DISPLAY always needs to be set - and I figured, there's a reason it
 is that way, so that's actually why I thought it made sense to use the same
 convention for WAYLAND_DISPLAY.

 Also, regarding Bill's first comment: yeah, that certainly works, but it
 feels like a workaround. It only gets more complicated if the app supports
 more backends - framebuffer, etc.

 On Wed, May 27, 2015 at 1:45 AM, Dima Ryazanov d...@gmail.com wrote:

 Yep, DISPLAY always needs to be set - and I figured, there's a reason

 On Tue, May 26, 2015 at 2:59 AM, Pekka Paalanen ppaala...@gmail.com
 wrote:

 On Tue, 26 May 2015 10:40:15 +0100
 Daniel Stone dan...@fooishbar.org wrote:

  Hi,
 
  On 26 May 2015 at 10:26, Giulio Camuffo giuliocamu...@gmail.com
 wrote:
   2015-05-26 12:21 GMT+03:00 Pekka Paalanen ppaala...@gmail.com:
   I have a vague recollection this has been proposed before, but I
 can't
   remember if there was any interest or discussion, nor what was the
   original intent behind defaulting to wayland-0.
 
  Probably to match X11's behaviour of using :0 in the absence of a
 $DISPLAY.

 Really? ;-)

 $ export -n DISPLAY
 $ xterm
 xterm: Xt error: Can't open display:
 xterm: DISPLAY is not set

 Geany and gqview fail to start, and konsole segfaults (lol).


 Thanks,
 pq




___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland-web] Fix a broken link

[Dima Ryazanov]

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 releases.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/releases.html b/releases.html
index 2454a55..f19f725 100644
--- a/releases.html
+++ b/releases.html
@@ -22,7 +22,7 @@
 lia href=releases/wayland-1.8.0.tar.xzwayland-1.8.0.tar.xz/a -
   - a 
href=http://lists.freedesktop.org/archives/wayland-devel/2015-June/022415.html;Wayland
 1.8.0 Release Announcement/a/li
 lia href=releases/weston-1.8.0.tar.xzweston-1.8.0.tar.xz/a
-  - a 
href=http://lists.freedesktop.org/archives/wayland-devel/2015-June/022416.htmlf;Weston
 1.8.0 Release Announcement/a/li
+  - a 
href=http://lists.freedesktop.org/archives/wayland-devel/2015-June/022416.html;Weston
 1.8.0 Release Announcement/a/li
 /ul
 
 h31.7.93 Release/h3
-- 
2.4.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] RFC: Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

[Dima Ryazanov]

Yep, DISPLAY always needs to be set - and I figured, there's a reason

On Tue, May 26, 2015 at 2:59 AM, Pekka Paalanen ppaala...@gmail.com wrote:

 On Tue, 26 May 2015 10:40:15 +0100
 Daniel Stone dan...@fooishbar.org wrote:

  Hi,
 
  On 26 May 2015 at 10:26, Giulio Camuffo giuliocamu...@gmail.com wrote:
   2015-05-26 12:21 GMT+03:00 Pekka Paalanen ppaala...@gmail.com:
   I have a vague recollection this has been proposed before, but I can't
   remember if there was any interest or discussion, nor what was the
   original intent behind defaulting to wayland-0.
 
  Probably to match X11's behaviour of using :0 in the absence of a
 $DISPLAY.

 Really? ;-)

 $ export -n DISPLAY
 $ xterm
 xterm: Xt error: Can't open display:
 xterm: DISPLAY is not set

 Geany and gqview fail to start, and konsole segfaults (lol).


 Thanks,
 pq

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] RFC: Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

[Dima Ryazanov]

(Oops, sent too soon by accident.)

Yep, DISPLAY always needs to be set - and I figured, there's a reason it is
that way, so that's actually why I thought it made sense to use the same
convention for WAYLAND_DISPLAY.

Also, regarding Bill's first comment: yeah, that certainly works, but it
feels like a workaround. It only gets more complicated if the app supports
more backends - framebuffer, etc.

On Wed, May 27, 2015 at 1:45 AM, Dima Ryazanov d...@gmail.com wrote:

 Yep, DISPLAY always needs to be set - and I figured, there's a reason

 On Tue, May 26, 2015 at 2:59 AM, Pekka Paalanen ppaala...@gmail.com
 wrote:

 On Tue, 26 May 2015 10:40:15 +0100
 Daniel Stone dan...@fooishbar.org wrote:

  Hi,
 
  On 26 May 2015 at 10:26, Giulio Camuffo giuliocamu...@gmail.com
 wrote:
   2015-05-26 12:21 GMT+03:00 Pekka Paalanen ppaala...@gmail.com:
   I have a vague recollection this has been proposed before, but I
 can't
   remember if there was any interest or discussion, nor what was the
   original intent behind defaulting to wayland-0.
 
  Probably to match X11's behaviour of using :0 in the absence of a
 $DISPLAY.

 Really? ;-)

 $ export -n DISPLAY
 $ xterm
 xterm: Xt error: Can't open display:
 xterm: DISPLAY is not set

 Geany and gqview fail to start, and konsole segfaults (lol).


 Thanks,
 pq



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland] RFC: Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

[Dima Ryazanov]

Although defaulting to wayland-0 seems convenient, it has an undesirable
side effect: clients may unintentionally connect to the wrong compositor.
Generally, it's safer to fail instead. Here's a real example:

In Fedora 22, Gtk+ prefers Wayland over X11, though the default session is still
a normal X11 Gnome session. When you launch a Gtk+ app, it will try Wayland,
fail, then try X11, and succesfully start up. That works fine.

Now suppose you launch Weston while running the Gnome session. Suddenly, all
of the Gtk+ apps launched from Gnome will show up inside Weston instead.
That's unexpected. There's also no good way to prevent that from happening
(other than perhaps setting WAYLAND_DISPLAY to an invalid value when launching
an app).

Not using wayland-0 as the default will solve that problem: an app launched
from the X11 Gnome session will use the X11 backend regardless of whether
there's a wayland compositor running at the same time.

Everything else should work as before. The compositor already sets
the WAYLAND_DISPLAY when starting the session, so the lack of the default value
should not make a difference to the user.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 doc/man/wl_display_connect.xml|  5 ++---
 doc/publican/sources/Protocol.xml |  8 
 src/wayland-client.c  | 10 ++
 src/wayland-server.c  |  6 +++---
 4 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/doc/man/wl_display_connect.xml b/doc/man/wl_display_connect.xml
index 7e6e05c..ded3cbd 100644
--- a/doc/man/wl_display_connect.xml
+++ b/doc/man/wl_display_connect.xml
@@ -57,9 +57,8 @@
   that was previously opened by a Wayland server. The server socket 
must
   be placed in envarXDG_RUNTIME_DIR/envar for this function to
   find it. The varnamename/varname argument specifies the name of
-  the socket or constantNULL/constant to use the default (which is
-  constantwayland-0/constant). The environment variable
-  envarWAYLAND_DISPLAY/envar replaces the default value. If
+  the socket or constantNULL/constant to use the default
+  (which is the value of envarWAYLAND_DISPLAY/envar). If
   envarWAYLAND_SOCKET/envar is set, this function behaves like
   functionwl_display_connect_to_fd/function with the 
file-descriptor
   number taken from the environment variable./para
diff --git a/doc/publican/sources/Protocol.xml 
b/doc/publican/sources/Protocol.xml
index 477063b..9464953 100644
--- a/doc/publican/sources/Protocol.xml
+++ b/doc/publican/sources/Protocol.xml
@@ -60,10 +60,10 @@
 titleWire Format/title
 para
   The protocol is sent over a UNIX domain stream socket, where the endpoint
-  usually is named systemitem class=servicewayland-0/systemitem
-  (although it can be changed via emphasisWAYLAND_DISPLAY/emphasis
-  in the environment).  The protocol is message-based.  A
-  message sent by a client to the server is called request.  A message
+  name is determined by the emphasisWAYLAND_DISPLAY/emphasis
+  environment variable.  Its value will usually be
+  systemitem class=servicewayland-0/systemitem.  The protocol is 
message-based.
+  A message sent by a client to the server is called request.  A message
   from the server to a client is called event.  Every message is
   structured as 32-bit words, values are represented in the host's
   byte-order.
diff --git a/src/wayland-client.c b/src/wayland-client.c
index ed108e1..2e612d0 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -759,8 +759,11 @@ connect_to_socket(const char *name)
 
if (name == NULL)
name = getenv(WAYLAND_DISPLAY);
-   if (name == NULL)
-   name = wayland-0;
+   if (name == NULL) {
+   wl_log(error: WAYLAND_DISPLAY not set in the environment.\n);
+   errno = ENOENT;
+   return -1;
+   }
 
fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
if (fd  0)
@@ -864,8 +867,7 @@ wl_display_connect_to_fd(int fd)
  * \return A \ref wl_display object or \c NULL on failure
  *
  * Connect to the Wayland display named \c name. If \c name is \c NULL,
- * its value will be replaced with the WAYLAND_DISPLAY environment
- * variable if it is set, otherwise display wayland-0 will be used.
+ * its value will be replaced with the WAYLAND_DISPLAY environment variable.
  *
  * \memberof wl_display
  */
diff --git a/src/wayland-server.c b/src/wayland-server.c
index ecbae68..acb090f 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -1205,8 +1205,8 @@ wl_display_add_socket_auto(struct wl_display *display)
  * connect to Wayland display.
  *
  * If NULL is passed as name, then it would look for WAYLAND_DISPLAY env
- * variable for the socket name. If WAYLAND_DISPLAY is not set, then default
- * wayland-0 is used.
+ * variable for the socket name. If WAYLAND_DISPLAY

Re: [PATCH v2 1/3] xwayland: Fix the addition and removal of outputs

[Dima Ryazanov]

Some more context here: currently, the output_handle_done function is not
really doing anything, but I haven't figured out yet how to fix it. These
patches fix a few trivial bugs, but there's more work to be done.

The call to RRScreenSizeNotify is a no-op: it expects the width/height of
xwl_screen-screen (not xwl_screen!) to be updated, and returns immediately
otherwise. However, if I update xwl_screen-screen-width and
xwl_screen-screen-height, then RRScreenSizeNotify will crash due to a
NULL pointer (probably because it's called too soon, and some of the dix
state is not initialized yet).

The only time output_handle_done is useful is during the xwayland
initialization: xwl_screen_init waits for xwl_screen-expecting_event to
become 0, then reads the width and height of the xwl_screen.

On Thu, May 21, 2015 at 9:23 AM, Jasper St. Pierre jstpie...@mecheye.net
wrote:

 Expecting anything atomic from X11 in the first place is a wrong
 assumption.

 On Thu, May 21, 2015 at 6:18 AM, Marek Chalupa mchqwe...@gmail.com
 wrote:
  Hi,
 
  On Sat, May 16, 2015 at 7:38 AM, Dima Ryazanov d...@gmail.com wrote:
 
  Add the output to the list when it's created rather than when its
  properties
  change (as pointed out by Marek Chalupa).
  Remove the output from the list when it's destroyed.
 
  Signed-off-by: Dima Ryazanov d...@gmail.com
  ---
   hw/xwayland/xwayland-output.c | 5 +++--
   1 file changed, 3 insertions(+), 2 deletions(-)
 
  diff --git a/hw/xwayland/xwayland-output.c
 b/hw/xwayland/xwayland-output.c
  index 155cbc1..9baf4eb 100644
  --- a/hw/xwayland/xwayland-output.c
  +++ b/hw/xwayland/xwayland-output.c
  @@ -120,8 +120,6 @@ output_handle_done(void *data, struct wl_output
  *wl_output)
   struct xwl_screen *xwl_screen = xwl_output-xwl_screen;
   int width, height;
 
  -xorg_list_append(xwl_output-link, xwl_screen-output_list);
  -
 
 
  As I pointed out in the other e-mail: I don't think this is right. The
  append is here on purpose to make the output update atomic.
  But maybe somebody more erudated should review it :)
 
 
   width = 0;
   height = 0;
   xorg_list_for_each_entry(xwl_output, xwl_screen-output_list,
 link)
  {
  @@ -177,6 +175,8 @@ xwl_output_create(struct xwl_screen *xwl_screen,
  uint32_t id)
   xwl_output-randr_crtc = RRCrtcCreate(xwl_screen-screen,
  xwl_output);
   xwl_output-randr_output = RROutputCreate(xwl_screen-screen, name,
 strlen(name),
 xwl_output);
  +xorg_list_append(xwl_output-link, xwl_screen-output_list);
  +
   RRCrtcGammaSetSize(xwl_output-randr_crtc, 256);
   RROutputSetCrtcs(xwl_output-randr_output, xwl_output-randr_crtc,
  1);
   RROutputSetConnection(xwl_output-randr_output, RR_Connected);
  @@ -190,6 +190,7 @@ xwl_output_destroy(struct xwl_output *xwl_output)
   wl_output_destroy(xwl_output-output);
   RRCrtcDestroy(xwl_output-randr_crtc);
   RROutputDestroy(xwl_output-randr_output);
  +xorg_list_del(xwl_output-link);
   free(xwl_output);
   }
 
  --
  2.4.0
 
 
 
  ___
  xorg-de...@lists.x.org: X.Org development
  Archives: http://lists.x.org/archives/xorg-devel
  Info: http://lists.x.org/mailman/listinfo/xorg-devel



 --
   Jasper

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] compositor-wayland: Handle window close events more gracefully

[Dima Ryazanov]

On Wed, May 20, 2015 at 12:00 AM, Bryce Harrington br...@osg.samsung.com
wrote:

 On Wed, May 20, 2015 at 09:39:54AM +0300, Pekka Paalanen wrote:
  On Wed, 20 May 2015 08:34:32 +0200
  Hardening rdp.eff...@gmail.com wrote:
 
   Le 20/05/2015 01:41, Bryce Harrington a écrit :
On Mon, May 18, 2015 at 11:14:16PM -0700, Dima Ryazanov wrote:
When a compositor window is closed, remove the output instead of
 just exiting.
   
(The if (!input-output) checks are kind of ugly - but I couldn't
 find
a better way to handle the output going away.)
   
Signed-off-by: Dima Ryazanov d...@gmail.com
Reviewed-by: Bryce Harrington br...@osg.samsung.com
   
---
 src/compositor-wayland.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)
   
   [...]
  
   
 if (frame_status(input-output-frame) 
 FRAME_STATUS_REPAINT)
   
 weston_output_schedule_repaint(input-output-base);
@@ -1521,7 +1537,7 @@ input_handle_keyboard_leave(void *data,
   
 focus = input-keyboard_focus;
 if (!focus)
-return; /* This shouldn't happen */
+return;
  
   Just a remark, if it's something that shouldn't happen it's a failing
   assert not a silent return, isn't it ?
 
  I'm assuming that after this patch, this actually can legally happen,
  and in that case we should just ignore it, because we are getting
  keyboard leave for something we already left by actively destroying it
  to begin with. Right?

 That's how I was understanding it.


Yeah, exactly.


 Bryce

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] compositor-wayland: Handle window close events more gracefully

[Dima Ryazanov]

On Tue, May 19, 2015 at 11:35 PM, Pekka Paalanen ppaala...@gmail.com
wrote:

 On Tue, 19 May 2015 16:41:19 -0700
 Bryce Harrington br...@osg.samsung.com wrote:

  On Mon, May 18, 2015 at 11:14:16PM -0700, Dima Ryazanov wrote:
   When a compositor window is closed, remove the output instead of just
 exiting.
  
   (The if (!input-output) checks are kind of ugly - but I couldn't
 find
   a better way to handle the output going away.)
  
   Signed-off-by: Dima Ryazanov d...@gmail.com
  Reviewed-by: Bryce Harrington br...@osg.samsung.com

 Acked-by: Pekka Paalanen pekka.paala...@collabora.co.uk

 If someone tests this patch (maybe Bryce already did?) that it doesn't
 cause any harm wrt. closing compositor windows in single and multi
 window cases, then I think this is suitable to go in before RC2. After
 RC2 not so much.

   @@ -1384,8 +1393,15 @@ input_handle_button(void *data, struct
 wl_pointer *pointer,
   return;
   }
  
   -   if (frame_status(input-output-frame) 
 FRAME_STATUS_CLOSE)
   -
  wl_display_terminate(input-compositor-base.wl_display);
   +   if (frame_status(input-output-frame) 
 FRAME_STATUS_CLOSE) {
   +   wayland_output_destroy(input-output-base);
   +   input-output = input-keyboard_focus = NULL;

 Please don't do multi-assignments like this, it's too easy to miss one
 of them when reading. Also setting output to keyboard_focus is strange
 to begin with, which is how I'd carelessly read this and go wtf.


Haha ok, I'll send out a fix.

Thanks,
 pq

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] compositor-wayland: Code cleanup

[Dima Ryazanov]

Don't do multi-assignments.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 src/compositor-wayland.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index aaf205b..935701a 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -1395,7 +1395,8 @@ input_handle_button(void *data, struct wl_pointer 
*pointer,
 
if (frame_status(input-output-frame)  FRAME_STATUS_CLOSE) {
wayland_output_destroy(input-output-base);
-   input-output = input-keyboard_focus = NULL;
+   input-output = NULL;
+   input-keyboard_focus = NULL;
 
if (wl_list_empty(input-compositor-base.output_list))

wl_display_terminate(input-compositor-base.wl_display);
-- 
2.4.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] compositor-wayland: Handle window close events more gracefully

[Dima Ryazanov]

When a compositor window is closed, remove the output instead of just exiting.

(The if (!input-output) checks are kind of ugly - but I couldn't find
a better way to handle the output going away.)

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 src/compositor-wayland.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index c9983e0..aaf205b 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -1307,6 +1307,9 @@ input_handle_pointer_leave(void *data, struct wl_pointer 
*pointer,
 {
struct wayland_input *input = data;
 
+   if (!input-output)
+   return;
+
if (input-output-frame) {
frame_pointer_leave(input-output-frame, input);
 
@@ -1327,6 +1330,9 @@ input_handle_motion(void *data, struct wl_pointer 
*pointer,
int32_t fx, fy;
enum theme_location location;
 
+   if (!input-output)
+   return;
+
if (input-output-frame) {
location = frame_pointer_motion(input-output-frame, input,
wl_fixed_to_int(x),
@@ -1368,6 +1374,9 @@ input_handle_button(void *data, struct wl_pointer 
*pointer,
enum frame_button_state fstate;
enum theme_location location;
 
+   if (!input-output)
+   return;
+
if (input-output-frame) {
fstate = state == WL_POINTER_BUTTON_STATE_PRESSED ?
FRAME_BUTTON_PRESSED : FRAME_BUTTON_RELEASED;
@@ -1384,8 +1393,15 @@ input_handle_button(void *data, struct wl_pointer 
*pointer,
return;
}
 
-   if (frame_status(input-output-frame)  FRAME_STATUS_CLOSE)
-   
wl_display_terminate(input-compositor-base.wl_display);
+   if (frame_status(input-output-frame)  FRAME_STATUS_CLOSE) {
+   wayland_output_destroy(input-output-base);
+   input-output = input-keyboard_focus = NULL;
+
+   if (wl_list_empty(input-compositor-base.output_list))
+   
wl_display_terminate(input-compositor-base.wl_display);
+
+   return;
+   }
 
if (frame_status(input-output-frame)  FRAME_STATUS_REPAINT)
weston_output_schedule_repaint(input-output-base);
@@ -1521,7 +1537,7 @@ input_handle_keyboard_leave(void *data,
 
focus = input-keyboard_focus;
if (!focus)
-   return; /* This shouldn't happen */
+   return;
 
focus-keyboard_count--;
if (!focus-keyboard_count  focus-frame) {
-- 
2.4.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH xwayland] xwayland: do not add output into output_list multiple times

[Dima Ryazanov]

I just made that change in my set of patches, and I think it fixes the
problem.

On Thu, May 14, 2015 at 9:43 AM, Dima Ryazanov d...@gmail.com wrote:

 Actually, why not just move xorg_list_append(xwl_output-link,
 xwl_screen-output_list); to xwl_output_create?

 I can't tell if there's a reason it's in xwl_output_done, or if it's just
 an oversight.

 On Thu, May 14, 2015 at 9:37 AM, Dima Ryazanov d...@gmail.com wrote:

 Oh wow, I was playing around with outputs, and never realized 
 output_handle_done
 was being called after any geometry change, not just after the output was
 created.

 On Thu, May 14, 2015 at 2:58 AM, Marek Chalupa mchqwe...@gmail.com
 wrote:

 output.done event can be sent even on some property change, not only
 when announcing the output. Therefore we must check if we already have it
 otherwise we may corrupt the list by adding it multiple times.

 This fixes bug when xwayland looped indefinitely in output.done handler
 and that can be reproduced following these steps (under X without
 multi-monitor setup):
  1) run weston --output-count=2
  2) run xterm, move it so that half is on one output
 and half on the other
  3) close second output, try run weston-terminal


 (I can only repro it after closing the first output, not the second one;
 is that what you meant?)


 weston sends updated outputs which trigger this bug.

 Signed-off-by: Marek Chalupa mchqwe...@gmail.com
 ---
  hw/xwayland/xwayland-output.c | 25 +++--
  1 file changed, 19 insertions(+), 6 deletions(-)

 diff --git a/hw/xwayland/xwayland-output.c
 b/hw/xwayland/xwayland-output.c
 index 155cbc1..0c96e87 100644
 --- a/hw/xwayland/xwayland-output.c
 +++ b/hw/xwayland/xwayland-output.c
 @@ -116,15 +116,28 @@ output_handle_mode(void *data, struct wl_output
 *wl_output, uint32_t flags,
  static void
  output_handle_done(void *data, struct wl_output *wl_output)
  {
 -struct xwl_output *xwl_output = data;
 +struct xwl_output *it, *xwl_output = data;
  struct xwl_screen *xwl_screen = xwl_output-xwl_screen;
 -int width, height;
 +int width = 0, height = 0, has_this_output = 0;
 +
 +xorg_list_for_each_entry(it, xwl_screen-output_list, link) {
 +/* output done event is sent even when some property
 + * of output is changed. That means that we may already
 + * have this output. If it is true, we must not add it
 + * into the output_list otherwise we'll corrupt it */
 +if (it == xwl_output)
 +has_this_output = 1;
 +
 +if (width  it-x + it-width)
 +width = it-x + it-width;
 +if (height  it-y + it-height)
 +height = it-y + it-height;
 +}

 -xorg_list_append(xwl_output-link, xwl_screen-output_list);
 +if (!has_this_output) {
 +xorg_list_append(xwl_output-link, xwl_screen-output_list);


 I think this line should also be moved here:
 xwl_screen-expecting_event--;

 (It might not matter since it's only used by xwl_screen_init - but the
 code seems to assume it would only be decremented once after the output is
 created.)

 -width = 0;
 -height = 0;
 -xorg_list_for_each_entry(xwl_output, xwl_screen-output_list,
 link) {
 +/* we did not check this output for new screen size, do it now
 */
  if (width  xwl_output-x + xwl_output-width)
  width = xwl_output-x + xwl_output-width;
  if (height  xwl_output-y + xwl_output-height)
 --
 2.1.0

 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel


 Just a thought... You could instead:
 - check if the output already exists
 - add it if necessary
 - update the width and height

 That way, the width/height calculation code won't be duplicated. (Though
 it will require iterating over output_list twice.) Anyways, it's up to you.



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2 3/3] xwayland: Destroy xwl_output when wl_output gets removed

[Dima Ryazanov]

This makes Xwayland correctly handle a monitor getting unplugged.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 hw/xwayland/xwayland-output.c |  1 +
 hw/xwayland/xwayland.c| 10 +-
 hw/xwayland/xwayland.h|  1 +
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index 41937b8..9ef8a48 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -163,6 +163,7 @@ xwl_output_create(struct xwl_screen *xwl_screen, uint32_t 
id)
 
 xwl_output-output = wl_registry_bind(xwl_screen-registry, id,
   wl_output_interface, 2);
+xwl_output-server_output_id = id;
 wl_output_add_listener(xwl_output-output, output_listener, xwl_output);
 
 snprintf(name, sizeof name, XWAYLAND%d, serial++);
diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 7e8d667..7c2eaed 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -410,7 +410,15 @@ registry_global(void *data, struct wl_registry *registry, 
uint32_t id,
 static void
 global_remove(void *data, struct wl_registry *registry, uint32_t name)
 {
-/* Nothing to do here, wl_compositor and wl_shm should not be removed */
+struct xwl_screen *xwl_screen = data;
+struct xwl_output *xwl_output;
+
+xorg_list_for_each_entry(xwl_output, xwl_screen-output_list, link) {
+if (xwl_output-server_output_id == name) {
+xwl_output_destroy(xwl_output);
+break;
+}
+}
 }
 
 static const struct wl_registry_listener registry_listener = {
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index cfb343d..70875e7 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -130,6 +130,7 @@ struct xwl_seat {
 struct xwl_output {
 struct xorg_list link;
 struct wl_output *output;
+uint32_t server_output_id;
 struct xwl_screen *xwl_screen;
 RROutputPtr randr_output;
 RRCrtcPtr randr_crtc;
-- 
2.4.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2 1/3] xwayland: Fix the addition and removal of outputs

[Dima Ryazanov]

Add the output to the list when it's created rather than when its properties
change (as pointed out by Marek Chalupa).
Remove the output from the list when it's destroyed.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 hw/xwayland/xwayland-output.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index 155cbc1..9baf4eb 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -120,8 +120,6 @@ output_handle_done(void *data, struct wl_output *wl_output)
 struct xwl_screen *xwl_screen = xwl_output-xwl_screen;
 int width, height;
 
-xorg_list_append(xwl_output-link, xwl_screen-output_list);
-
 width = 0;
 height = 0;
 xorg_list_for_each_entry(xwl_output, xwl_screen-output_list, link) {
@@ -177,6 +175,8 @@ xwl_output_create(struct xwl_screen *xwl_screen, uint32_t 
id)
 xwl_output-randr_crtc = RRCrtcCreate(xwl_screen-screen, xwl_output);
 xwl_output-randr_output = RROutputCreate(xwl_screen-screen, name,
   strlen(name), xwl_output);
+xorg_list_append(xwl_output-link, xwl_screen-output_list);
+
 RRCrtcGammaSetSize(xwl_output-randr_crtc, 256);
 RROutputSetCrtcs(xwl_output-randr_output, xwl_output-randr_crtc, 1);
 RROutputSetConnection(xwl_output-randr_output, RR_Connected);
@@ -190,6 +190,7 @@ xwl_output_destroy(struct xwl_output *xwl_output)
 wl_output_destroy(xwl_output-output);
 RRCrtcDestroy(xwl_output-randr_crtc);
 RROutputDestroy(xwl_output-randr_output);
+xorg_list_del(xwl_output-link);
 free(xwl_output);
 }
 
-- 
2.4.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2 2/3] xwayland: Remove a useless out-of-memory check

[Dima Ryazanov]

snprintf does not allocate memory, so we can never get an out-of-memory error.

(Also, the error handler would free xwl_output after it was already registered
as an event listener.)

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 hw/xwayland/xwayland-output.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index 9baf4eb..41937b8 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -165,11 +165,7 @@ xwl_output_create(struct xwl_screen *xwl_screen, uint32_t 
id)
   wl_output_interface, 2);
 wl_output_add_listener(xwl_output-output, output_listener, xwl_output);
 
-if (snprintf(name, sizeof name, XWAYLAND%d, serial++)  0) {
-ErrorF(create_output ENOMEM\n);
-free(xwl_output);
-return NULL;
-}
+snprintf(name, sizeof name, XWAYLAND%d, serial++);
 
 xwl_output-xwl_screen = xwl_screen;
 xwl_output-randr_crtc = RRCrtcCreate(xwl_screen-screen, xwl_output);
-- 
2.4.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH xwayland] xwayland: do not add output into output_list multiple times

[Dima Ryazanov]

Actually, why not just move xorg_list_append(xwl_output-link,
xwl_screen-output_list); to xwl_output_create?

I can't tell if there's a reason it's in xwl_output_done, or if it's just
an oversight.

On Thu, May 14, 2015 at 9:37 AM, Dima Ryazanov d...@gmail.com wrote:

 Oh wow, I was playing around with outputs, and never realized 
 output_handle_done
 was being called after any geometry change, not just after the output was
 created.

 On Thu, May 14, 2015 at 2:58 AM, Marek Chalupa mchqwe...@gmail.com
 wrote:

 output.done event can be sent even on some property change, not only
 when announcing the output. Therefore we must check if we already have it
 otherwise we may corrupt the list by adding it multiple times.

 This fixes bug when xwayland looped indefinitely in output.done handler
 and that can be reproduced following these steps (under X without
 multi-monitor setup):
  1) run weston --output-count=2
  2) run xterm, move it so that half is on one output
 and half on the other
  3) close second output, try run weston-terminal


 (I can only repro it after closing the first output, not the second one;
 is that what you meant?)


 weston sends updated outputs which trigger this bug.

 Signed-off-by: Marek Chalupa mchqwe...@gmail.com
 ---
  hw/xwayland/xwayland-output.c | 25 +++--
  1 file changed, 19 insertions(+), 6 deletions(-)

 diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
 index 155cbc1..0c96e87 100644
 --- a/hw/xwayland/xwayland-output.c
 +++ b/hw/xwayland/xwayland-output.c
 @@ -116,15 +116,28 @@ output_handle_mode(void *data, struct wl_output
 *wl_output, uint32_t flags,
  static void
  output_handle_done(void *data, struct wl_output *wl_output)
  {
 -struct xwl_output *xwl_output = data;
 +struct xwl_output *it, *xwl_output = data;
  struct xwl_screen *xwl_screen = xwl_output-xwl_screen;
 -int width, height;
 +int width = 0, height = 0, has_this_output = 0;
 +
 +xorg_list_for_each_entry(it, xwl_screen-output_list, link) {
 +/* output done event is sent even when some property
 + * of output is changed. That means that we may already
 + * have this output. If it is true, we must not add it
 + * into the output_list otherwise we'll corrupt it */
 +if (it == xwl_output)
 +has_this_output = 1;
 +
 +if (width  it-x + it-width)
 +width = it-x + it-width;
 +if (height  it-y + it-height)
 +height = it-y + it-height;
 +}

 -xorg_list_append(xwl_output-link, xwl_screen-output_list);
 +if (!has_this_output) {
 +xorg_list_append(xwl_output-link, xwl_screen-output_list);


 I think this line should also be moved here:
 xwl_screen-expecting_event--;

 (It might not matter since it's only used by xwl_screen_init - but the
 code seems to assume it would only be decremented once after the output is
 created.)

 -width = 0;
 -height = 0;
 -xorg_list_for_each_entry(xwl_output, xwl_screen-output_list, link)
 {
 +/* we did not check this output for new screen size, do it now */
  if (width  xwl_output-x + xwl_output-width)
  width = xwl_output-x + xwl_output-width;
  if (height  xwl_output-y + xwl_output-height)
 --
 2.1.0

 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel


 Just a thought... You could instead:
 - check if the output already exists
 - add it if necessary
 - update the width and height

 That way, the width/height calculation code won't be duplicated. (Though
 it will require iterating over output_list twice.) Anyways, it's up to you.


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH xwayland] xwayland: do not add output into output_list multiple times

[Dima Ryazanov]

Oh wow, I was playing around with outputs, and never realized
output_handle_done
was being called after any geometry change, not just after the output was
created.

On Thu, May 14, 2015 at 2:58 AM, Marek Chalupa mchqwe...@gmail.com wrote:

 output.done event can be sent even on some property change, not only
 when announcing the output. Therefore we must check if we already have it
 otherwise we may corrupt the list by adding it multiple times.

 This fixes bug when xwayland looped indefinitely in output.done handler
 and that can be reproduced following these steps (under X without
 multi-monitor setup):
  1) run weston --output-count=2
  2) run xterm, move it so that half is on one output
 and half on the other
  3) close second output, try run weston-terminal


(I can only repro it after closing the first output, not the second one; is
that what you meant?)


 weston sends updated outputs which trigger this bug.

 Signed-off-by: Marek Chalupa mchqwe...@gmail.com
 ---
  hw/xwayland/xwayland-output.c | 25 +++--
  1 file changed, 19 insertions(+), 6 deletions(-)

 diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
 index 155cbc1..0c96e87 100644
 --- a/hw/xwayland/xwayland-output.c
 +++ b/hw/xwayland/xwayland-output.c
 @@ -116,15 +116,28 @@ output_handle_mode(void *data, struct wl_output
 *wl_output, uint32_t flags,
  static void
  output_handle_done(void *data, struct wl_output *wl_output)
  {
 -struct xwl_output *xwl_output = data;
 +struct xwl_output *it, *xwl_output = data;
  struct xwl_screen *xwl_screen = xwl_output-xwl_screen;
 -int width, height;
 +int width = 0, height = 0, has_this_output = 0;
 +
 +xorg_list_for_each_entry(it, xwl_screen-output_list, link) {
 +/* output done event is sent even when some property
 + * of output is changed. That means that we may already
 + * have this output. If it is true, we must not add it
 + * into the output_list otherwise we'll corrupt it */
 +if (it == xwl_output)
 +has_this_output = 1;
 +
 +if (width  it-x + it-width)
 +width = it-x + it-width;
 +if (height  it-y + it-height)
 +height = it-y + it-height;
 +}

 -xorg_list_append(xwl_output-link, xwl_screen-output_list);
 +if (!has_this_output) {
 +xorg_list_append(xwl_output-link, xwl_screen-output_list);


I think this line should also be moved here:
xwl_screen-expecting_event--;

(It might not matter since it's only used by xwl_screen_init - but the code
seems to assume it would only be decremented once after the output is
created.)

-width = 0;
 -height = 0;
 -xorg_list_for_each_entry(xwl_output, xwl_screen-output_list, link) {
 +/* we did not check this output for new screen size, do it now */
  if (width  xwl_output-x + xwl_output-width)
  width = xwl_output-x + xwl_output-width;
  if (height  xwl_output-y + xwl_output-height)
 --
 2.1.0

 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel


Just a thought... You could instead:
- check if the output already exists
- add it if necessary
- update the width and height

That way, the width/height calculation code won't be duplicated. (Though it
will require iterating over output_list twice.) Anyways, it's up to you.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 3/4] xwayland: Keep a list of wayland globals

[Dima Ryazanov]

On Thu, May 14, 2015 at 12:57 AM, Marek Chalupa mchqwe...@gmail.com wrote:

 On Tue, May 12, 2015 at 7:21 PM, Dima Ryazanov d...@gmail.com wrote:

 The logic is pretty much copied from weston's clients/window.c.

 Signed-off-by: Dima Ryazanov d...@gmail.com
 ---
  hw/xwayland/xwayland.c | 25 -
  hw/xwayland/xwayland.h |  8 
  2 files changed, 32 insertions(+), 1 deletion(-)

 diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
 index 7e8d667..e99fbac 100644
 --- a/hw/xwayland/xwayland.c
 +++ b/hw/xwayland/xwayland.c
 @@ -383,6 +383,17 @@ registry_global(void *data, struct wl_registry
 *registry, uint32_t id,
  const char *interface, uint32_t version)
  {
  struct xwl_screen *xwl_screen = data;
 +struct xwl_global *xwl_global;
 +
 +xwl_global = calloc(sizeof *xwl_global, 1);
 +if (xwl_global == NULL) {
 +ErrorF(registry_global ENOMEM\n);
 +return;
 +}
 +xwl_global-name = id;
 +xwl_global-interface = strdup(interface);


 You should probably check if the strdup succeeds here. In the following
 patch you do
   if (strcmp(xwl_global-interface, wl_output) == 0)
 and if the strdup returns NULL, then this contition will be false even
 thoug it should be true.


Oh, good catch.




 +xwl_global-version = version;
 +xorg_list_add(xwl_global-link, xwl_screen-global_list);

  if (strcmp(interface, wl_compositor) == 0) {
  xwl_screen-compositor =
 @@ -410,7 +421,18 @@ registry_global(void *data, struct wl_registry
 *registry, uint32_t id,
  static void
  global_remove(void *data, struct wl_registry *registry, uint32_t name)
  {
 -/* Nothing to do here, wl_compositor and wl_shm should not be
 removed */
 +struct xwl_screen *xwl_screen = data;
 +struct xwl_global *xwl_global, *next_xwl_global;
 +
 +xorg_list_for_each_entry_safe(xwl_global, next_xwl_global,
 +  xwl_screen-global_list, link) {
 +if (xwl_global-name != name)
 +continue;
 +
 +xorg_list_del(xwl_global-link);
 +free(xwl_global-interface);
 +free(xwl_global);


 Here a break would be handy, so that we won't iterate over the rest of
 globals after we found the one we need.


Sure.


 +}
  }

  static const struct wl_registry_listener registry_listener = {
 @@ -562,6 +584,7 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char
 **argv)
  listen_on_fds(xwl_screen);
  }

 +xorg_list_init(xwl_screen-global_list);
  xorg_list_init(xwl_screen-output_list);
  xorg_list_init(xwl_screen-seat_list);
  xorg_list_init(xwl_screen-damage_window_list);
 diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
 index cfb343d..2ba5312 100644
 --- a/hw/xwayland/xwayland.h
 +++ b/hw/xwayland/xwayland.h
 @@ -64,6 +64,7 @@ struct xwl_screen {
  UnrealizeWindowProcPtr UnrealizeWindow;
  XYToWindowProcPtr XYToWindow;

 +struct xorg_list global_list;
  struct xorg_list output_list;
  struct xorg_list seat_list;
  struct xorg_list damage_window_list;
 @@ -95,6 +96,13 @@ struct xwl_screen {
  struct glamor_context *glamor_ctx;
  };

 +struct xwl_global {
 +uint32_t name;
 +char *interface;
 +uint32_t version;
 +struct xorg_list link;
 +};
 +
  struct xwl_window {
  struct xwl_screen *xwl_screen;
  struct wl_surface *surface;
 --
 2.4.0

 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel


 Isn't storing all globals redundant for this purpose? Couldn't we add the
 name (id) into struct xwl_output and then
 iterate just over the output_list?


Correct - if we only care about xwl_output, then the globals list is
unnecessary. I only did it that way because that's how weston does it, and
it feels more generic - it makes it easy to handle different types of
globals in the future. That said, it offers no performance advantages since
it's just iterating over the whole list. A hash table would make more sense.

Anyways, I'll remove it for now.



 Thanks,
 Marek


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 1/4] xwayland: Remove the output from the list after destroying it

[Dima Ryazanov]

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 hw/xwayland/xwayland-output.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index 155cbc1..1d75d0b 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -190,6 +190,7 @@ xwl_output_destroy(struct xwl_output *xwl_output)
 wl_output_destroy(xwl_output-output);
 RRCrtcDestroy(xwl_output-randr_crtc);
 RROutputDestroy(xwl_output-randr_output);
+xorg_list_del(xwl_output-link);
 free(xwl_output);
 }
 
-- 
2.4.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 2/4] xwayland: Remove a useless out-of-memory check

[Dima Ryazanov]

snprintf does not allocate memory, so we can never get an out-of-memory error.

(Also, the error handler would free xwl_output after it was already registered
as an event listener.)

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 hw/xwayland/xwayland-output.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index 1d75d0b..4949363 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -167,11 +167,7 @@ xwl_output_create(struct xwl_screen *xwl_screen, uint32_t 
id)
   wl_output_interface, 2);
 wl_output_add_listener(xwl_output-output, output_listener, xwl_output);
 
-if (snprintf(name, sizeof name, XWAYLAND%d, serial++)  0) {
-ErrorF(create_output ENOMEM\n);
-free(xwl_output);
-return NULL;
-}
+snprintf(name, sizeof name, XWAYLAND%d, serial++);
 
 xwl_output-xwl_screen = xwl_screen;
 xwl_output-randr_crtc = RRCrtcCreate(xwl_screen-screen, xwl_output);
-- 
2.4.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 4/4] xwayland: Destroy xwl_output when wl_output gets removed

[Dima Ryazanov]

This makes Xwayland correctly handle a monitor getting unplugged.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 hw/xwayland/xwayland-output.c |  1 +
 hw/xwayland/xwayland.c| 16 
 hw/xwayland/xwayland.h|  1 +
 3 files changed, 18 insertions(+)

diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index 4949363..4ee74fb 100644
--- a/hw/xwayland/xwayland-output.c
+++ b/hw/xwayland/xwayland-output.c
@@ -165,6 +165,7 @@ xwl_output_create(struct xwl_screen *xwl_screen, uint32_t 
id)
 
 xwl_output-output = wl_registry_bind(xwl_screen-registry, id,
   wl_output_interface, 2);
+xwl_output-server_output_id = id;
 wl_output_add_listener(xwl_output-output, output_listener, xwl_output);
 
 snprintf(name, sizeof name, XWAYLAND%d, serial++);
diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index e99fbac..a763b02 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -379,6 +379,19 @@ xwl_screen_post_damage(struct xwl_screen *xwl_screen)
 }
 
 static void
+xwl_screen_destroy_output(struct xwl_screen *xwl_screen, uint32_t id)
+{
+struct xwl_output *xwl_output;
+
+xorg_list_for_each_entry(xwl_output, xwl_screen-output_list, link) {
+if (xwl_output-server_output_id == id) {
+xwl_output_destroy(xwl_output);
+break;
+}
+}
+}
+
+static void
 registry_global(void *data, struct wl_registry *registry, uint32_t id,
 const char *interface, uint32_t version)
 {
@@ -429,6 +442,9 @@ global_remove(void *data, struct wl_registry *registry, 
uint32_t name)
 if (xwl_global-name != name)
 continue;
 
+if (strcmp(xwl_global-interface, wl_output) == 0)
+xwl_screen_destroy_output(xwl_screen, name);
+
 xorg_list_del(xwl_global-link);
 free(xwl_global-interface);
 free(xwl_global);
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index 2ba5312..c4342a4 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -138,6 +138,7 @@ struct xwl_seat {
 struct xwl_output {
 struct xorg_list link;
 struct wl_output *output;
+uint32_t server_output_id;
 struct xwl_screen *xwl_screen;
 RROutputPtr randr_output;
 RRCrtcPtr randr_crtc;
-- 
2.4.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 3/4] xwayland: Keep a list of wayland globals

[Dima Ryazanov]

The logic is pretty much copied from weston's clients/window.c.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 hw/xwayland/xwayland.c | 25 -
 hw/xwayland/xwayland.h |  8 
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 7e8d667..e99fbac 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -383,6 +383,17 @@ registry_global(void *data, struct wl_registry *registry, 
uint32_t id,
 const char *interface, uint32_t version)
 {
 struct xwl_screen *xwl_screen = data;
+struct xwl_global *xwl_global;
+
+xwl_global = calloc(sizeof *xwl_global, 1);
+if (xwl_global == NULL) {
+ErrorF(registry_global ENOMEM\n);
+return;
+}
+xwl_global-name = id;
+xwl_global-interface = strdup(interface);
+xwl_global-version = version;
+xorg_list_add(xwl_global-link, xwl_screen-global_list);
 
 if (strcmp(interface, wl_compositor) == 0) {
 xwl_screen-compositor =
@@ -410,7 +421,18 @@ registry_global(void *data, struct wl_registry *registry, 
uint32_t id,
 static void
 global_remove(void *data, struct wl_registry *registry, uint32_t name)
 {
-/* Nothing to do here, wl_compositor and wl_shm should not be removed */
+struct xwl_screen *xwl_screen = data;
+struct xwl_global *xwl_global, *next_xwl_global;
+
+xorg_list_for_each_entry_safe(xwl_global, next_xwl_global,
+  xwl_screen-global_list, link) {
+if (xwl_global-name != name)
+continue;
+
+xorg_list_del(xwl_global-link);
+free(xwl_global-interface);
+free(xwl_global);
+}
 }
 
 static const struct wl_registry_listener registry_listener = {
@@ -562,6 +584,7 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
 listen_on_fds(xwl_screen);
 }
 
+xorg_list_init(xwl_screen-global_list);
 xorg_list_init(xwl_screen-output_list);
 xorg_list_init(xwl_screen-seat_list);
 xorg_list_init(xwl_screen-damage_window_list);
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index cfb343d..2ba5312 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -64,6 +64,7 @@ struct xwl_screen {
 UnrealizeWindowProcPtr UnrealizeWindow;
 XYToWindowProcPtr XYToWindow;
 
+struct xorg_list global_list;
 struct xorg_list output_list;
 struct xorg_list seat_list;
 struct xorg_list damage_window_list;
@@ -95,6 +96,13 @@ struct xwl_screen {
 struct glamor_context *glamor_ctx;
 };
 
+struct xwl_global {
+uint32_t name;
+char *interface;
+uint32_t version;
+struct xorg_list link;
+};
+
 struct xwl_window {
 struct xwl_screen *xwl_screen;
 struct wl_surface *surface;
-- 
2.4.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v2] gl-renderer: If an XRGB format is requested but unavailable, try ARGB

[Dima Ryazanov]

I don't know if the alloca change is a good idea. Some people consider it bad
practice
http://stackoverflow.com/questions/1018853/why-is-alloca-not-considered-good-practice,
and looks like it's not used anywhere in wayland/weston code - but someone
else should make that call.

Otherwise, though, looks good.

On Tue, May 5, 2015 at 2:22 PM, Derek Foreman der...@osg.samsung.com
wrote:

 Recent versions of Mesa have stopped exposing XRGB visuals for gl on
 some Intel GPUs.  While this may be changed in Mesa eventually, it's
 not impossible that some other hardware in the future won't provide
 XRGB visuals either.

 Let's try again with an ARGB visual if XRGB is unavailable.  Since
 we're not changing the scanout buffer format, and our current
 rendering loop always results in saturated alpha in the frame buffer,
 it should be Just Fine(tm) - and probably better than just exiting.

 Signed-off-by: Derek Foreman der...@osg.samsung.com
 ---

 Dima Ryazanov called me out for fallback_format() not working on all
 endians,
 and I've reworked the loop to be a single loop instead of two, similar to
 Daniel's suggestion (but still keeping the NULL visual_id means give me
 the
 first match semantic of the original)

 I've also replaced calloc with aloca so I don't have to worry about freeing
 the array on return, which simplifies things a little bit.  I didn't bother
 zeroing out the array, since it's filled in by eglChooseConfig.

 It's still an ugly function. :)

  src/gl-renderer.c | 57
 +--
  1 file changed, 43 insertions(+), 14 deletions(-)

 diff --git a/src/gl-renderer.c b/src/gl-renderer.c
 index ae3122f..a4fd3a0 100644
 --- a/src/gl-renderer.c
 +++ b/src/gl-renderer.c
 @@ -934,6 +934,14 @@ output_rotate_damage(struct weston_output *output,
 go-border_damage[go-buffer_damage_index] = border_status;
  }

 +/* NOTE: We now allow falling back to ARGB  gl visual ids when XRGB is
 + * unavailable, so we're assuming the background has no transparency
 + * and that everything with a blend, like drop shadows, will have
 something
 + * opaque (like the background) drawn underneath it.
 + *
 + * Depending on the underlying hardware, violating that assumption could
 + * result in seeing through to another display plane.
 + */
  static void
  gl_renderer_repaint_output(struct weston_output *output,
   pixman_region32_t *output_damage)
 @@ -1897,6 +1905,15 @@ log_egl_config_info(EGLDisplay egldpy, EGLConfig
 eglconfig)
 weston_log_continue( unknown\n);
  }

 +static EGLint
 +fallback_format(EGLint format)
 +{
 +   if ((format  0xFF) != 'X')
 +   return 0;
 +
 +   return (format  0xFF00) | 'A';
 +}
 +
  static int
  egl_choose_config(struct gl_renderer *gr, const EGLint *attribs,
   const EGLint *visual_id,
 @@ -1904,41 +1921,53 @@ egl_choose_config(struct gl_renderer *gr, const
 EGLint *attribs,
  {
 EGLint count = 0;
 EGLint matched = 0;
 +   EGLint fallback_id;
 EGLConfig *configs;
 +   EGLConfig fallback_config = 0;
 int i;

 if (!eglGetConfigs(gr-egl_display, NULL, 0, count) || count  1)
 return -1;

 -   configs = calloc(count, sizeof *configs);
 +   configs = alloca(count * sizeof *configs);
 if (!configs)
 return -1;

 if (!eglChooseConfig(gr-egl_display, attribs, configs,
   count, matched))
 -   goto out;
 +   return -1;
 +
 +   if (!matched)
 +   return -1;

 +   if (!visual_id) {
 +   *config_out = configs[0];
 +   return 0;
 +   }
 +
 +   fallback_id = fallback_format(*visual_id);
 for (i = 0; i  matched; ++i) {
 EGLint id;

 -   if (visual_id) {
 -   if (!eglGetConfigAttrib(gr-egl_display,
 -   configs[i], EGL_NATIVE_VISUAL_ID,
 -   id))
 -   continue;
 +   if (!eglGetConfigAttrib(gr-egl_display,
 +   configs[i], EGL_NATIVE_VISUAL_ID,
 +   id))
 +   continue;

 -   if (id != 0  id != *visual_id)
 -   continue;
 +   if (id == *visual_id) {
 +   *config_out = configs[i];
 +   return 0;
 }
 +   if (id == fallback_id)
 +   fallback_config = configs[i];
 +   }

 -   *config_out = configs[i];
 -
 -   free(configs);
 +   if (fallback_config) {
 +   weston_log(Falling back to ARGB visual\n);
 +   *config_out = fallback_config;
 return 0;
 }

 -out:
 -   free(configs);
 return -1;
  }

 --
 2.1.4

[PATCH weston] xwm: Fix the window decoration hints.

[Dima Ryazanov]

Enable all hints by default. This fixes the Maximize button in apps that
don't set any hints - e.g., xclock or Firefox. (There's still a problem, though:
decorate is sometimes treated as a boolean, sometimes as a bitmask.)

Handle MWM_DECOR_ALL correctly. It looks like it's supposed to invert the values
of the rest of the flags.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 xwayland/window-manager.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index cab7e20..78bb13d 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -94,6 +94,10 @@ struct motif_wm_hints {
 #define MWM_DECOR_MINIMIZE  (1L  5)
 #define MWM_DECOR_MAXIMIZE  (1L  6)
 
+#define MWM_DECOR_EVERYTHING \
+   (MWM_DECOR_BORDER | MWM_DECOR_RESIZEH | MWM_DECOR_TITLE | \
+MWM_DECOR_MENU | MWM_DECOR_MINIMIZE | MWM_DECOR_MAXIMIZE)
+
 #define MWM_INPUT_MODELESS 0
 #define MWM_INPUT_PRIMARY_APPLICATION_MODAL 1
 #define MWM_INPUT_SYSTEM_MODAL 2
@@ -425,7 +429,7 @@ weston_wm_window_read_properties(struct weston_wm_window 
*window)
 props[i].atom,
 XCB_ATOM_ANY, 0, 2048);
 
-   window-decorate = !window-override_redirect;
+   window-decorate = window-override_redirect ? 0 : MWM_DECOR_EVERYTHING;
window-size_hints.flags = 0;
window-motif_hints.flags = 0;
window-delete_window = 0;
@@ -495,9 +499,15 @@ weston_wm_window_read_properties(struct weston_wm_window 
*window)
memcpy(window-motif_hints,
   xcb_get_property_value(reply),
   sizeof window-motif_hints);
-   if (window-motif_hints.flags  MWM_HINTS_DECORATIONS)
-   window-decorate =
-   window-motif_hints.decorations;
+   if (window-motif_hints.flags  MWM_HINTS_DECORATIONS) {
+   if (window-motif_hints.decorations  
MWM_DECOR_ALL)
+   /* MWM_DECOR_ALL means all except the 
other values listed. */
+   window-decorate =
+   MWM_DECOR_EVERYTHING  
(~window-motif_hints.decorations);
+   else
+   window-decorate =
+   window-motif_hints.decorations;
+   }
break;
default:
break;
-- 
2.1.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] xwayland: Implement smooth scrolling

[Dima Ryazanov]

We don't even need to simulate button clicks; it's done automatically.
This also fixes scrolling in Qt5 apps.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 hw/xwayland/xwayland-input.c | 53 +---
 hw/xwayland/xwayland.h   |  4 
 2 files changed, 16 insertions(+), 41 deletions(-)

diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index cc3bc53..9d8c28e 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -43,7 +43,7 @@ static int
 xwl_pointer_proc(DeviceIntPtr device, int what)
 {
 #define NBUTTONS 10
-#define NAXES 2
+#define NAXES 4
 BYTE map[NBUTTONS + 1];
 int i = 0;
 Atom btn_labels[NBUTTONS] = { 0 };
@@ -67,8 +67,10 @@ xwl_pointer_proc(DeviceIntPtr device, int what)
 
 axes_labels[0] = XIGetKnownProperty(AXIS_LABEL_PROP_ABS_X);
 axes_labels[1] = XIGetKnownProperty(AXIS_LABEL_PROP_ABS_Y);
+axes_labels[2] = XIGetKnownProperty(AXIS_LABEL_PROP_REL_HWHEEL);
+axes_labels[3] = XIGetKnownProperty(AXIS_LABEL_PROP_REL_WHEEL);
 
-if (!InitValuatorClassDeviceStruct(device, 2, btn_labels,
+if (!InitValuatorClassDeviceStruct(device, NAXES, btn_labels,
GetMotionHistorySize(), Absolute))
 return BadValue;
 
@@ -77,6 +79,13 @@ xwl_pointer_proc(DeviceIntPtr device, int what)
0, 0x, 1, 0, 1, Absolute);
 InitValuatorAxisStruct(device, 1, axes_labels[1],
0, 0x, 1, 0, 1, Absolute);
+InitValuatorAxisStruct(device, 2, axes_labels[2],
+   NO_AXIS_LIMITS, NO_AXIS_LIMITS, 0, 0, 0, 
Relative);
+InitValuatorAxisStruct(device, 3, axes_labels[3],
+   NO_AXIS_LIMITS, NO_AXIS_LIMITS, 0, 0, 0, 
Relative);
+
+SetScrollValuator(device, 2, SCROLL_TYPE_HORIZONTAL, 1.0, 
SCROLL_FLAG_NONE);
+SetScrollValuator(device, 3, SCROLL_TYPE_VERTICAL, 1.0, 
SCROLL_FLAG_PREFERRED);
 
 if (!InitPtrFeedbackClassDeviceStruct(device, xwl_pointer_control))
 return BadValue;
@@ -259,54 +268,24 @@ pointer_handle_axis(void *data, struct wl_pointer 
*pointer,
 uint32_t time, uint32_t axis, wl_fixed_t value)
 {
 struct xwl_seat *xwl_seat = data;
-int index, count;
-int i, val;
+int index;
 const int divisor = 10;
 ValuatorMask mask;
 
-if (time - xwl_seat-scroll_time  2000) {
-xwl_seat-vertical_scroll = 0;
-xwl_seat-horizontal_scroll = 0;
-}
-xwl_seat-scroll_time = time;
-
-/* FIXME: Need to do proper smooth scrolling here! */
 switch (axis) {
 case WL_POINTER_AXIS_VERTICAL_SCROLL:
-xwl_seat-vertical_scroll += value / divisor;
-val = wl_fixed_to_int(xwl_seat-vertical_scroll);
-xwl_seat-vertical_scroll -= wl_fixed_from_int(val);
-
-if (val = -1)
-index = 4;
-else if (val = 1)
-index = 5;
-else
-return;
+index = 3;
 break;
 case WL_POINTER_AXIS_HORIZONTAL_SCROLL:
-xwl_seat-horizontal_scroll += value / divisor;
-val = wl_fixed_to_int(xwl_seat-horizontal_scroll);
-xwl_seat-horizontal_scroll -= wl_fixed_from_int(val);
-
-if (val = -1)
-index = 6;
-else if (val = 1)
-index = 7;
-else
-return;
+index = 2;
 break;
 default:
 return;
 }
 
 valuator_mask_zero(mask);
-
-count = abs(val);
-for (i = 0; i  count; i++) {
-QueuePointerEvents(xwl_seat-pointer, ButtonPress, index, 0, mask);
-QueuePointerEvents(xwl_seat-pointer, ButtonRelease, index, 0, mask);
-}
+valuator_mask_set_double(mask, index, wl_fixed_to_double(value) / 
divisor);
+QueuePointerEvents(xwl_seat-pointer, MotionNotify, 0, POINTER_RELATIVE, 
mask);
 }
 
 static const struct wl_pointer_listener pointer_listener = {
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index bfffa71..cfb343d 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -122,10 +122,6 @@ struct xwl_seat {
 struct xorg_list link;
 CursorPtr x_cursor;
 
-wl_fixed_t horizontal_scroll;
-wl_fixed_t vertical_scroll;
-uint32_t scroll_time;
-
 size_t keymap_size;
 char *keymap;
 struct wl_surface *keyboard_focus;
-- 
2.1.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 2/2] desktop-shell: Remove the panel popup

[Dima Ryazanov]

It doesn't work anymore, and it never did anything useful.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 clients/desktop-shell.c | 33 -
 1 file changed, 33 deletions(-)

diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index ac2928f..e2f9f80 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -145,26 +145,6 @@ sigchild_handler(int s)
fprintf(stderr, child %d exited\n, pid);
 }
 
-static void
-menu_func(void *data, struct input *input, int index)
-{
-   printf(Selected index %d from a panel menu.\n, index);
-}
-
-static void
-show_menu(struct panel *panel, struct input *input, uint32_t time)
-{
-   int32_t x, y;
-   static const char *entries[] = {
-   Roy, Pris, Leon, Zhora
-   };
-
-   input_get_position(input, x, y);
-   window_show_menu(window_get_display(panel-window),
-input, time, panel-window,
-x - 10, y - 10, menu_func, entries, 4);
-}
-
 static int
 is_desktop_painted(struct desktop *desktop)
 {
@@ -454,18 +434,6 @@ panel_add_clock(struct panel *panel)
 }
 
 static void
-panel_button_handler(struct widget *widget,
-struct input *input, uint32_t time,
-uint32_t button,
-enum wl_pointer_button_state state, void *data)
-{
-   struct panel *panel = data;
-
-   if (button == BTN_RIGHT  state == WL_POINTER_BUTTON_STATE_PRESSED)
-   show_menu(panel, input, time);
-}
-
-static void
 panel_resize_handler(struct widget *widget,
 int32_t width, int32_t height, void *data)
 {
@@ -553,7 +521,6 @@ panel_create(struct desktop *desktop)
 
widget_set_redraw_handler(panel-widget, panel_redraw_handler);
widget_set_resize_handler(panel-widget, panel_resize_handler);
-   widget_set_button_handler(panel-widget, panel_button_handler);

panel_add_clock(panel);
 
-- 
2.1.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 1/2] desktop-shell: Require a popup parent to be a shell surface

[Dima Ryazanov]

Currently, the shell crashes if the parent is not a shell surface. Instead,
send an error to the client.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 desktop-shell/shell.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index f7c928e..96aa8f3 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -3393,7 +3393,8 @@ add_popup_grab(struct shell_surface *shsurf,
parent = get_shell_surface(shsurf-parent);
top_surface = get_top_popup(shseat);
if (shell_surface_is_xdg_popup(shsurf) 
-   ((top_surface == NULL  !shell_surface_is_xdg_surface(parent)) ||
+   (!parent ||
+(top_surface == NULL  !shell_surface_is_xdg_surface(parent)) ||
 (top_surface != NULL  parent != top_surface))) {
wl_resource_post_error(shsurf-owner-resource,
   XDG_POPUP_ERROR_NOT_THE_TOPMOST_POPUP,
@@ -4098,13 +4099,14 @@ create_xdg_popup(struct shell_client *owner, void 
*shell,
 {
struct shell_surface *shsurf, *parent_shsurf;
 
-   /* Verify that we are creating the top most popup when mapping,
-* as its not until then we know whether it was mapped as most
+   /* Verify that we are creating the topmost popup when mapping,
+* as it's not until then we know whether it was mapped as most
 * top level or not. */
 
parent_shsurf = get_shell_surface(parent);
-   if (!shell_surface_is_xdg_popup(parent_shsurf) 
-   !shell_surface_is_xdg_surface(parent_shsurf)) {
+   if (!parent_shsurf ||
+   (!shell_surface_is_xdg_popup(parent_shsurf) 
+!shell_surface_is_xdg_surface(parent_shsurf))) {
wl_resource_post_error(owner-resource,
   XDG_POPUP_ERROR_INVALID_PARENT,
   xdg_popup parent was invalid);
-- 
2.1.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] desktop-shell: Fix a crash when right-clicking the panel

[Dima Ryazanov]

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 ppaala...@gmail.com wrote:

 On Mon, 6 Apr 2015 13:27:23 -0700
 Dima Ryazanov d...@gmail.com 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 shell surface? Then we could require that the
  popup's parent is a shell surface and simplify the error check.

 No, that won't work. panel is a special surface role, it cannot also
 be a shell_surface.

 I suppose the answer to this whole problem is to remove the whole panel
 popup thing. It never had anything useful, right?


 Thanks,
 pq

  On Mon, Apr 6, 2015 at 12:33 PM, Derek Foreman der...@osg.samsung.com
  wrote:
 
   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 parent is
a shell surface - but that's not always the case.
   
Signed-off-by: Dima Ryazanov d...@gmail.com
---
 desktop-shell/shell.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)
   
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index f7c928e..0159547 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -3392,7 +3392,7 @@ add_popup_grab(struct shell_surface *shsurf,
   
  parent = get_shell_surface(shsurf-parent);
  top_surface = get_top_popup(shseat);
- if (shell_surface_is_xdg_popup(shsurf) 
+ if (parent  shell_surface_is_xdg_popup(shsurf) 
  
   This part broke in da6ecd0cc52
  
   Your patch definitely stops the crash for me, which is good.  :)
  
   I think this part's ok, but I'm not 100% sure we're still going to send
   the new not-top-level-popup error when we're supposed to now...
  
  ((top_surface == NULL 
   !shell_surface_is_xdg_surface(parent)) ||
   (top_surface != NULL  parent != top_surface))) {
  wl_resource_post_error(shsurf-owner-resource,
@@ -4098,12 +4098,13 @@ create_xdg_popup(struct shell_client *owner,
   void *shell,
 {
  struct shell_surface *shsurf, *parent_shsurf;
   
- /* Verify that we are creating the top most popup when mapping,
-  * as its not until then we know whether it was mapped as most
+ /* Verify that we are creating the topmost popup when mapping,
+  * as it's not until then we know whether it was mapped as most
   * top level or not. */
  
   The grammar fix-ups look good to me.
  
  parent_shsurf = get_shell_surface(parent);
- if (!shell_surface_is_xdg_popup(parent_shsurf) 
+ if (parent_shsurf 
  
   This part broke in 24185e2561...
  
   I wonder if we should be doing a more comprehensive test here - it
 looks
   like some invalid parent resources could get past this test?
  
+ !shell_surface_is_xdg_popup(parent_shsurf) 
  !shell_surface_is_xdg_surface(parent_shsurf)) {
  wl_resource_post_error(owner-resource,
 XDG_POPUP_ERROR_INVALID_PARENT,
   
  
  
  


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] desktop-shell: Fix a crash when right-clicking the panel

[Dima Ryazanov]

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 surface and simplify the error check.

On Mon, Apr 6, 2015 at 12:33 PM, Derek Foreman der...@osg.samsung.com
wrote:

 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 parent is
  a shell surface - but that's not always the case.
 
  Signed-off-by: Dima Ryazanov d...@gmail.com
  ---
   desktop-shell/shell.c | 9 +
   1 file changed, 5 insertions(+), 4 deletions(-)
 
  diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
  index f7c928e..0159547 100644
  --- a/desktop-shell/shell.c
  +++ b/desktop-shell/shell.c
  @@ -3392,7 +3392,7 @@ add_popup_grab(struct shell_surface *shsurf,
 
parent = get_shell_surface(shsurf-parent);
top_surface = get_top_popup(shseat);
  - if (shell_surface_is_xdg_popup(shsurf) 
  + if (parent  shell_surface_is_xdg_popup(shsurf) 

 This part broke in da6ecd0cc52

 Your patch definitely stops the crash for me, which is good.  :)

 I think this part's ok, but I'm not 100% sure we're still going to send
 the new not-top-level-popup error when we're supposed to now...

((top_surface == NULL 
 !shell_surface_is_xdg_surface(parent)) ||
 (top_surface != NULL  parent != top_surface))) {
wl_resource_post_error(shsurf-owner-resource,
  @@ -4098,12 +4098,13 @@ create_xdg_popup(struct shell_client *owner,
 void *shell,
   {
struct shell_surface *shsurf, *parent_shsurf;
 
  - /* Verify that we are creating the top most popup when mapping,
  -  * as its not until then we know whether it was mapped as most
  + /* Verify that we are creating the topmost popup when mapping,
  +  * as it's not until then we know whether it was mapped as most
 * top level or not. */

 The grammar fix-ups look good to me.

parent_shsurf = get_shell_surface(parent);
  - if (!shell_surface_is_xdg_popup(parent_shsurf) 
  + if (parent_shsurf 

 This part broke in 24185e2561...

 I wonder if we should be doing a more comprehensive test here - it looks
 like some invalid parent resources could get past this test?

  + !shell_surface_is_xdg_popup(parent_shsurf) 
!shell_surface_is_xdg_surface(parent_shsurf)) {
wl_resource_post_error(owner-resource,
   XDG_POPUP_ERROR_INVALID_PARENT,
 



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] desktop-shell: Fix a crash when right-clicking the panel

[Dima Ryazanov]

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 d...@gmail.com
---
 desktop-shell/shell.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index f7c928e..0159547 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -3392,7 +3392,7 @@ add_popup_grab(struct shell_surface *shsurf,
 
parent = get_shell_surface(shsurf-parent);
top_surface = get_top_popup(shseat);
-   if (shell_surface_is_xdg_popup(shsurf) 
+   if (parent  shell_surface_is_xdg_popup(shsurf) 
((top_surface == NULL  !shell_surface_is_xdg_surface(parent)) ||
 (top_surface != NULL  parent != top_surface))) {
wl_resource_post_error(shsurf-owner-resource,
@@ -4098,12 +4098,13 @@ create_xdg_popup(struct shell_client *owner, void 
*shell,
 {
struct shell_surface *shsurf, *parent_shsurf;
 
-   /* Verify that we are creating the top most popup when mapping,
-* as its not until then we know whether it was mapped as most
+   /* Verify that we are creating the topmost popup when mapping,
+* as it's not until then we know whether it was mapped as most
 * top level or not. */
 
parent_shsurf = get_shell_surface(parent);
-   if (!shell_surface_is_xdg_popup(parent_shsurf) 
+   if (parent_shsurf 
+   !shell_surface_is_xdg_popup(parent_shsurf) 
!shell_surface_is_xdg_surface(parent_shsurf)) {
wl_resource_post_error(owner-resource,
   XDG_POPUP_ERROR_INVALID_PARENT,
-- 
2.1.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] Fix Back, Forward, and other special mouse buttons in the X11 compositor.

[Dima Ryazanov]

I actually feel the same way - but kept the old style just in case. I'll
update it.

On Tue, Feb 3, 2015 at 2:36 PM, Peter Hutterer peter.hutte...@who-t.net
wrote:

 On Mon, Dec 22, 2014 at 11:51:05AM -0800, Dima Ryazanov wrote:
  They're off by 4 because of the scroll buttons.
 
  (However, if you test them in XWayland, they'll appear to work because
  XWayland has the same bug; see
  http://lists.x.org/archives/xorg-devel/2014-December/044987.html)
 
  Signed-off-by: Dima Ryazanov d...@gmail.com
  ---
   src/compositor-x11.c | 5 -
   1 file changed, 4 insertions(+), 1 deletion(-)
 
  diff --git a/src/compositor-x11.c b/src/compositor-x11.c
  index 29f2119..af9de6f 100644
  --- a/src/compositor-x11.c
  +++ b/src/compositor-x11.c
  @@ -1015,7 +1015,10 @@ x11_compositor_deliver_button_event(struct
 x11_compositor *c,
 
switch (button_event-detail) {
default:
  - button = button_event-detail + BTN_LEFT - 1;
  + button = button_event-detail + BTN_SIDE - 8;
  + break;
  + case 1:
  + button = BTN_LEFT;
break;
case 2:
button = BTN_MIDDLE;
  --
  2.1.0

 Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
 though I'd prefer having the default at the bottom of the switch
 case

 Cheers,
Peter

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston v2] Fix Back, Forward, and other special mouse buttons in the X11 compositor.

[Dima Ryazanov]

They're off by 4 because of the scroll buttons.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 src/compositor-x11.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index 5863446..2792251 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -1017,8 +1017,8 @@ x11_compositor_deliver_button_event(struct x11_compositor 
*c,
update_xkb_state_from_core(c, button_event-state);
 
switch (button_event-detail) {
-   default:
-   button = button_event-detail + BTN_LEFT - 1;
+   case 1:
+   button = BTN_LEFT;
break;
case 2:
button = BTN_MIDDLE;
@@ -1056,6 +1056,9 @@ x11_compositor_deliver_button_event(struct x11_compositor 
*c,
WL_POINTER_AXIS_HORIZONTAL_SCROLL,
DEFAULT_AXIS_STEP_DISTANCE);
return;
+   default:
+   button = button_event-detail + BTN_SIDE - 8;
+   break;
}
 
notify_button(c-core_seat,
-- 
2.1.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] Fix Back, Forward, and other special mouse buttons in the X11 compositor.

[Dima Ryazanov]

Looks like this patch got discarded (according to patchwork)?

This one is different from http://patchwork.freedesktop.org/patch/39499/.
That one fixed the Wayland-X11 key code translation; this one fixes
X11-Wayland.
On Dec 22, 2014 11:51 AM, Dima Ryazanov d...@gmail.com wrote:

 They're off by 4 because of the scroll buttons.

 (However, if you test them in XWayland, they'll appear to work because
 XWayland has the same bug; see
 http://lists.x.org/archives/xorg-devel/2014-December/044987.html)

 Signed-off-by: Dima Ryazanov d...@gmail.com
 ---
  src/compositor-x11.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

 diff --git a/src/compositor-x11.c b/src/compositor-x11.c
 index 29f2119..af9de6f 100644
 --- a/src/compositor-x11.c
 +++ b/src/compositor-x11.c
 @@ -1015,7 +1015,10 @@ x11_compositor_deliver_button_event(struct
 x11_compositor *c,

 switch (button_event-detail) {
 default:
 -   button = button_event-detail + BTN_LEFT - 1;
 +   button = button_event-detail + BTN_SIDE - 8;
 +   break;
 +   case 1:
 +   button = BTN_LEFT;
 break;
 case 2:
 button = BTN_MIDDLE;
 --
 2.1.0


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Fix Back, Forward, and other special mouse buttons in XWayland.

[Dima Ryazanov]

Sure, I'll fix that.

On Sun, Dec 21, 2014 at 8:43 PM, Peter Hutterer peter.hutte...@who-t.net
wrote:

 On Sun, Dec 21, 2014 at 02:39:02AM -0800, Dima Ryazanov wrote:
  Currently, the indexes are off by 4 because of the scroll buttons.
 
  Signed-off-by: Dima Ryazanov d...@gmail.com
  ---
   hw/xwayland/xwayland-input.c | 7 ++-
   1 file changed, 6 insertions(+), 1 deletion(-)
 
  diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
  index b8c543c..ad30c31 100644
  --- a/hw/xwayland/xwayland-input.c
  +++ b/hw/xwayland/xwayland-input.c
  @@ -233,6 +233,9 @@ pointer_handle_button(void *data, struct wl_pointer
 *pointer, uint32_t serial,
   xwl_seat-xwl_screen-serial = serial;
 
   switch (button) {
  +case BTN_LEFT:
  +index = 1;
  +break;
   case BTN_MIDDLE:
   index = 2;
   break;
  @@ -240,7 +243,9 @@ pointer_handle_button(void *data, struct wl_pointer
 *pointer, uint32_t serial,
   index = 3;
   break;
   default:
  -index = button - BTN_LEFT + 1;
  +/* Skip indexes 4-7: they are used for vertical and horizontal
 scroll.
  +   The rest of the buttons go in order: BTN_LEFT + 3 becomes 8,
 etc. */
  +index = button - BTN_LEFT + 5;

 tbh, I'd use 8 + button - BTN_SIDE here, that's less confusing (and is what
 we do in e.g. evdev). but either way,

 Reviewed-by: Peter Hutterer peter.hutte...@who-t.net

 Cheers,
Peter

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2] Fix Back, Forward, and other special mouse buttons in XWayland.

[Dima Ryazanov]

Currently, the indexes are off by 4 because of the scroll buttons.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 hw/xwayland/xwayland-input.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index b8c543c..5e20418 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -233,6 +233,9 @@ pointer_handle_button(void *data, struct wl_pointer 
*pointer, uint32_t serial,
 xwl_seat-xwl_screen-serial = serial;
 
 switch (button) {
+case BTN_LEFT:
+index = 1;
+break;
 case BTN_MIDDLE:
 index = 2;
 break;
@@ -240,7 +243,9 @@ pointer_handle_button(void *data, struct wl_pointer 
*pointer, uint32_t serial,
 index = 3;
 break;
 default:
-index = button - BTN_LEFT + 1;
+/* Skip indexes 4-7: they are used for vertical and horizontal scroll.
+   The rest of the buttons go in order: BTN_SIDE becomes 8, etc. */
+index = 8 + button - BTN_SIDE;
 break;
 }
 
-- 
2.1.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] Fix Back, Forward, and other special mouse buttons in the X11 compositor.

[Dima Ryazanov]

They're off by 4 because of the scroll buttons.

(However, if you test them in XWayland, they'll appear to work because
XWayland has the same bug; see
http://lists.x.org/archives/xorg-devel/2014-December/044987.html)

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 src/compositor-x11.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index 29f2119..af9de6f 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -1015,7 +1015,10 @@ x11_compositor_deliver_button_event(struct 
x11_compositor *c,
 
switch (button_event-detail) {
default:
-   button = button_event-detail + BTN_LEFT - 1;
+   button = button_event-detail + BTN_SIDE - 8;
+   break;
+   case 1:
+   button = BTN_LEFT;
break;
case 2:
button = BTN_MIDDLE;
-- 
2.1.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Fix Back, Forward, and other special mouse buttons in XWayland.

[Dima Ryazanov]

Currently, the indexes are off by 4 because of the scroll buttons.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 hw/xwayland/xwayland-input.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index b8c543c..ad30c31 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -233,6 +233,9 @@ pointer_handle_button(void *data, struct wl_pointer 
*pointer, uint32_t serial,
 xwl_seat-xwl_screen-serial = serial;
 
 switch (button) {
+case BTN_LEFT:
+index = 1;
+break;
 case BTN_MIDDLE:
 index = 2;
 break;
@@ -240,7 +243,9 @@ pointer_handle_button(void *data, struct wl_pointer 
*pointer, uint32_t serial,
 index = 3;
 break;
 default:
-index = button - BTN_LEFT + 1;
+/* Skip indexes 4-7: they are used for vertical and horizontal scroll.
+   The rest of the buttons go in order: BTN_LEFT + 3 becomes 8, etc. */
+index = button - BTN_LEFT + 5;
 break;
 }
 
-- 
2.1.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 3/4] queue-test: Add another assertion

[Dima Ryazanov]

I've brought this up once, but looks like it's acceptable in the test suite
since it already relies on asserts:
http://lists.freedesktop.org/archives/wayland-devel/2013-February/007454.html
On Sep 28, 2014 6:57 PM, Bill Spitzak spit...@gmail.com wrote:

 On 09/28/2014 11:49 AM, Karsten Otto wrote:

  -   wl_display_roundtrip(display);
 +   assert(wl_display_roundtrip(display) != -1);


 You can't put code that you require to run in an assert.

 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] xwayland: Clean up the WM properly if X server crashes

[Dima Ryazanov]

The X cleanup code uses wxs-wm to check if the WM has been created - but that
variable was never initialized. So if X crashes, the WM doesn't get destroyed,
causing a crash when it tries to repaint a window.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 xwayland/launcher.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xwayland/launcher.c b/xwayland/launcher.c
index 70703a4..fad6219 100644
--- a/xwayland/launcher.c
+++ b/xwayland/launcher.c
@@ -43,7 +43,7 @@ handle_sigusr1(int signal_number, void *data)
/* We'd be safer if we actually had the struct
 * signalfd_siginfo from the signalfd data and could verify
 * this came from Xwayland.*/
-   weston_wm_create(wxs, wxs-wm_fd);
+   wxs-wm = weston_wm_create(wxs, wxs-wm_fd);
wl_event_source_remove(wxs-sigusr1_source);
 
return 1;
@@ -159,8 +159,10 @@ weston_xserver_shutdown(struct weston_xserver *wxs)
}
close(wxs-abstract_fd);
close(wxs-unix_fd);
-   if (wxs-wm)
+   if (wxs-wm) {
weston_wm_destroy(wxs-wm);
+   wxs-wm = NULL;
+   }
wxs-loop = NULL;
 }
 
-- 
1.9.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH xwayland] Set the view to NULL when unmapping an X11 window

[Dima Ryazanov]

Oh interesting... I can fix the crash by checking for a NULL pointer,
though I don't know if that's the proper fix. Anyways, I'll send out the
new patches.


On Fri, Nov 15, 2013 at 12:44 AM, Axel Davy d...@clipper.ens.fr wrote:

  I have tested your patch, but it doesn't solve all the bugs occuring in
 XWayland because of views (take vlc, go to the menu, crash).

 It appears ok to me to set view to NULL at these locations, but there's
 probably something more to do.

 Axel Davy

 On 15/11/2013, Dima Ryazanov wrote :

 Ping :)


 On Fri, Nov 1, 2013 at 12:46 AM, Dima Ryazanov d...@gmail.com wrote:

 Fixes a crash caused by accessing a deleted view in
 weston_wm_window_schedule_repaint. It can be easily reproduced by switching
 between menus in Firefox.

 Signed-off-by: Dima Ryazanov d...@gmail.com
 ---
  src/xwayland/window-manager.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
 index b2776a0..5ee9480 100644
 --- a/src/xwayland/window-manager.c
 +++ b/src/xwayland/window-manager.c
 @@ -902,6 +902,7 @@ weston_wm_handle_unmap_notify(struct weston_wm *wm,
 xcb_generic_event_t *event)
 wl_list_remove(window-surface_destroy_listener.link);
 window-surface = NULL;
 window-shsurf = NULL;
 +   window-view = NULL;
 xcb_unmap_window(wm-conn, window-frame_id);
  }

 @@ -2028,6 +2029,7 @@ surface_destroy(struct wl_listener *listener, void
 *data)
 Don't try to use it later. */
 window-shsurf = NULL;
 window-surface = NULL;
 +   window-view = NULL;
  }

  static struct weston_wm_window *
 --
 1.8.3.2




 ___
 wayland-devel mailing 
 listwayland-devel@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/wayland-devel



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH xwayland 1/3] Set the view to NULL when unmapping an X11 window

[Dima Ryazanov]

Fixes a crash caused by accessing a deleted view in 
weston_wm_window_schedule_repaint. It can be easily reproduced by switching 
between menus in Firefox.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 src/xwayland/window-manager.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index b2776a0..5ee9480 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -902,6 +902,7 @@ weston_wm_handle_unmap_notify(struct weston_wm *wm, 
xcb_generic_event_t *event)
wl_list_remove(window-surface_destroy_listener.link);
window-surface = NULL;
window-shsurf = NULL;
+   window-view = NULL;
xcb_unmap_window(wm-conn, window-frame_id);
 }
 
@@ -2028,6 +2029,7 @@ surface_destroy(struct wl_listener *listener, void *data)
Don't try to use it later. */
window-shsurf = NULL;
window-surface = NULL;
+   window-view = NULL;
 }
 
 static struct weston_wm_window *
-- 
1.8.3.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH xwayland 3/3] Check if the frame exists before reading its size

[Dima Ryazanov]

This fixes crashes caused by popup windows that don't have override_redirect
(e.g., menus in VLC and KDE apps), though I don't know if this is correct.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 src/xwayland/window-manager.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index 6d29026..eea0349 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -497,7 +497,7 @@ weston_wm_window_get_frame_size(struct weston_wm_window 
*window,
if (window-fullscreen) {
*width = window-width;
*height = window-height;
-   } else if (window-decorate) {
+   } else if (window-decorate  window-frame) {
*width = frame_width(window-frame);
*height = frame_height(window-frame);
} else {
@@ -515,7 +515,7 @@ weston_wm_window_get_child_position(struct weston_wm_window 
*window,
if (window-fullscreen) {
*x = 0;
*y = 0;
-   } else if (window-decorate) {
+   } else if (window-decorate  window-frame) {
frame_interior(window-frame, x, y, NULL, NULL);
} else {
*x = t-margin;
-- 
1.8.3.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH xwayland 2/3] Check for frame being NULL before setting/unsetting flags

[Dima Ryazanov]

Fixes a crash in Firefox when clicking an install plugin popup.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 src/xwayland/window-manager.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index 5ee9480..6d29026 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -695,12 +695,14 @@ weston_wm_window_activate(struct wl_listener *listener, 
void *data)
}
 
if (wm-focus_window) {
-   frame_unset_flag(wm-focus_window-frame, FRAME_FLAG_ACTIVE);
+   if (wm-focus_window-frame)
+   frame_unset_flag(wm-focus_window-frame, 
FRAME_FLAG_ACTIVE);
weston_wm_window_schedule_repaint(wm-focus_window);
}
wm-focus_window = window;
if (wm-focus_window) {
-   frame_set_flag(wm-focus_window-frame, FRAME_FLAG_ACTIVE);
+   if (wm-focus_window-frame)
+   frame_set_flag(wm-focus_window-frame, 
FRAME_FLAG_ACTIVE);
weston_wm_window_schedule_repaint(wm-focus_window);
}
 }
-- 
1.8.3.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH xwayland] Set the view to NULL when unmapping an X11 window

[Dima Ryazanov]

Ping :)


On Fri, Nov 1, 2013 at 12:46 AM, Dima Ryazanov d...@gmail.com wrote:

 Fixes a crash caused by accessing a deleted view in
 weston_wm_window_schedule_repaint. It can be easily reproduced by switching
 between menus in Firefox.

 Signed-off-by: Dima Ryazanov d...@gmail.com
 ---
  src/xwayland/window-manager.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
 index b2776a0..5ee9480 100644
 --- a/src/xwayland/window-manager.c
 +++ b/src/xwayland/window-manager.c
 @@ -902,6 +902,7 @@ weston_wm_handle_unmap_notify(struct weston_wm *wm,
 xcb_generic_event_t *event)
 wl_list_remove(window-surface_destroy_listener.link);
 window-surface = NULL;
 window-shsurf = NULL;
 +   window-view = NULL;
 xcb_unmap_window(wm-conn, window-frame_id);
  }

 @@ -2028,6 +2029,7 @@ surface_destroy(struct wl_listener *listener, void
 *data)
 Don't try to use it later. */
 window-shsurf = NULL;
 window-surface = NULL;
 +   window-view = NULL;
  }

  static struct weston_wm_window *
 --
 1.8.3.2


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH xwayland] Set the view to NULL when unmapping an X11 window

[Dima Ryazanov]

Fixes a crash caused by accessing a deleted view in 
weston_wm_window_schedule_repaint. It can be easily reproduced by switching 
between menus in Firefox.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 src/xwayland/window-manager.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index b2776a0..5ee9480 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -902,6 +902,7 @@ weston_wm_handle_unmap_notify(struct weston_wm *wm, 
xcb_generic_event_t *event)
wl_list_remove(window-surface_destroy_listener.link);
window-surface = NULL;
window-shsurf = NULL;
+   window-view = NULL;
xcb_unmap_window(wm-conn, window-frame_id);
 }
 
@@ -2028,6 +2029,7 @@ surface_destroy(struct wl_listener *listener, void *data)
Don't try to use it later. */
window-shsurf = NULL;
window-surface = NULL;
+   window-view = NULL;
 }
 
 static struct weston_wm_window *
-- 
1.8.3.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH xwayland] xwayland: Probe outputs on preinit

[Dima Ryazanov]

Actually, never mind. Not sure what the problem was, but I updated
everything just now, and xwayland works!


On Sat, Sep 7, 2013 at 1:51 AM, Jonas Ådahl jad...@gmail.com wrote:

 On Thu, Sep 05, 2013 at 09:00:51PM -0700, Dima Ryazanov wrote:

 Hi,

  This actually made xwayland work for me when running weston using the X11
  backend.
 
  If I run it using the drm backend, though, it still fails:

 Odd, because with the patch, xwayland works also using the drm backend
 of weston on my machine, also using the intel X driver.

 
  [102316.702] (==) intel(0): Backing store disabled
   [102316.702] (==) intel(0): Silken mouse enabled
   [102316.702] (II) intel(0): Initializing HW Cursor
   [102316.702] (II) intel(0): RandR 1.2 enabled, ignore the following
 RandR
   disabled message.
   [102316.702] (==) intel(0): DPMS enabled
   [102316.702] (II) intel(0): Set up textured video
   [102316.703] (II) intel(0): direct rendering: DRI2 Enabled
   [102316.703] (==) intel(0): hotplug detection: enabled
   [102316.703] (WW) intel(0): drmSetMaster failed: Permission denied
   [102316.703] (EE)
   Fatal server error:
   [102316.703] (EE) AddScreen/ScreenInit failed for driver 0
   [102316.703] (EE
   [102316.704] (EE)
   Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
   [102316.704] (EE) Please also check the log file at
   /home/dima/install/var/log/Xorg.1.log for additional information.
   [102316.704] (EE)
 
 
  (I'm assuming that's the bug you were trying to fix?)

 Yes, these are the same errors I got.

 Jonas

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH xwayland] xwayland: Probe outputs on preinit

[Dima Ryazanov]

This actually made xwayland work for me when running weston using the X11
backend.

If I run it using the drm backend, though, it still fails:

[102316.702] (==) intel(0): Backing store disabled
 [102316.702] (==) intel(0): Silken mouse enabled
 [102316.702] (II) intel(0): Initializing HW Cursor
 [102316.702] (II) intel(0): RandR 1.2 enabled, ignore the following RandR
 disabled message.
 [102316.702] (==) intel(0): DPMS enabled
 [102316.702] (II) intel(0): Set up textured video
 [102316.703] (II) intel(0): direct rendering: DRI2 Enabled
 [102316.703] (==) intel(0): hotplug detection: enabled
 [102316.703] (WW) intel(0): drmSetMaster failed: Permission denied
 [102316.703] (EE)
 Fatal server error:
 [102316.703] (EE) AddScreen/ScreenInit failed for driver 0
 [102316.703] (EE)
 [102316.704] (EE)
 Please consult the The X.Org Foundation support
  at http://wiki.x.org
  for help.
 [102316.704] (EE) Please also check the log file at
 /home/dima/install/var/log/Xorg.1.log for additional information.
 [102316.704] (EE)


(I'm assuming that's the bug you were trying to fix?)


On Sun, Sep 1, 2013 at 2:14 PM, Jonas Ådahl jad...@gmail.com wrote:

 When running xwayland, calls to xf86SetDesiredModes() would fail due to
 the probed modes list not being populated. This was previously done
 indirectly by calling xf86InitialConfiguration() and now needs to be
 done explicitly instead.

 Signed-off-by: Jonas Ådahl jad...@gmail.com
 ---
  hw/xfree86/xwayland/xwayland-output.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/hw/xfree86/xwayland/xwayland-output.c
 b/hw/xfree86/xwayland/xwayland-output.c
 index 28003ba..53829c3 100644
 --- a/hw/xfree86/xwayland/xwayland-output.c
 +++ b/hw/xfree86/xwayland/xwayland-output.c
 @@ -431,6 +431,8 @@ xwayland_screen_preinit_output(struct xwl_screen
 *xwl_screen, ScrnInfoPtr scrnin
  FatalError(failed to dispatch Wayland events: %s\n,
 strerror(errno));
  }

 +xf86ProbeOutputModes(scrninfo, 0, 0);
 +
  xwl_screen-outputs_initialized = TRUE;

  xf86SetScrnInfoModes(scrninfo);
 --
 1.8.1.2

 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 05/12] event-loop-test: Add some more assertions and work around a FreeBSD bug

[Dima Ryazanov]

On Fri, Feb 15, 2013 at 7:56 AM, Philip Withnall phi...@tecnocode.co.ukwrote:

 There’s a bug in FreeBSD’s handling of timer events which means we have to
 be more relaxed about how we check when timer events have happened because
 FreeBSD can’t manage enough precision on scheduling the events.

 Signed-off-by: Philip Withnall phi...@tecnocode.co.uk
 ---
  tests/event-loop-test.c | 22 --
  1 file changed, 16 insertions(+), 6 deletions(-)

 diff --git a/tests/event-loop-test.c b/tests/event-loop-test.c
 index c46d3b0..cf9dabe 100644
 --- a/tests/event-loop-test.c
 +++ b/tests/event-loop-test.c
 @@ -155,10 +155,11 @@ TEST(event_loop_signal)

 source = wl_event_loop_add_signal(loop, SIGUSR1,
   signal_callback, got_it);
 -   wl_event_loop_dispatch(loop, 0);
 +   assert(source);
 +   assert(wl_event_loop_dispatch(loop, 0) == 0);


You shouldn't put code with side effects inside asserts, since it'll be
compiled out in release mode.


 assert(!got_it);
 -   kill(getpid(), SIGUSR1);
 -   wl_event_loop_dispatch(loop, 0);
 +   assert(kill(getpid(), SIGUSR1) == 0);
 +   assert(wl_event_loop_dispatch(loop, 0) == 0);
 assert(got_it);

 wl_event_source_remove(source);
 @@ -183,12 +184,21 @@ TEST(event_loop_timer)
 int got_it = 0;

 source = wl_event_loop_add_timer(loop, timer_callback, got_it);
 -   wl_event_source_timer_update(source, 10);
 -   wl_event_loop_dispatch(loop, 0);
 +   assert(source);
 +   assert(wl_event_source_timer_update(source, 10) == 0);
 +   assert(wl_event_loop_dispatch(loop, 0) == 0);
 assert(!got_it);
 -   wl_event_loop_dispatch(loop, 20);
 +   /* FreeBSD has a bug where it converts ms_timeout to ticks; it
 always adds 1 to the tick count.
 +* Consequently, we need to grossly overcompensate here.
 +* See:
 http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2012-07/msg00319.html*/
 +   assert(wl_event_loop_dispatch(loop, 50) == 0);
 assert(got_it);

 +   /* Check it doesn't fire again. */
 +   got_it = 0;
 +   assert(wl_event_loop_dispatch(loop, 20) == 0);
 +   assert(!got_it);
 +
 wl_event_source_remove(source);
 wl_event_loop_destroy(loop);
  }
 --
 1.7.11.7


 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 05/12] event-loop-test: Add some more assertions and work around a FreeBSD bug

[Dima Ryazanov]

Ah, got it, sorry.

On Fri, Feb 15, 2013 at 10:20 AM, Pekka Paalanen ppaala...@gmail.comwrote:

 On Fri, 15 Feb 2013 09:48:35 -0500
 Dima Ryazanov d...@gmail.com wrote:

  On Fri, Feb 15, 2013 at 7:56 AM, Philip Withnall phi...@tecnocode.co.uk
 wrote:
 
   There’s a bug in FreeBSD’s handling of timer events which means we
 have to
   be more relaxed about how we check when timer events have happened
 because
   FreeBSD can’t manage enough precision on scheduling the events.
  
   Signed-off-by: Philip Withnall phi...@tecnocode.co.uk
   ---
tests/event-loop-test.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
  
   diff --git a/tests/event-loop-test.c b/tests/event-loop-test.c
   index c46d3b0..cf9dabe 100644
   --- a/tests/event-loop-test.c
   +++ b/tests/event-loop-test.c
   @@ -155,10 +155,11 @@ TEST(event_loop_signal)
  
   source = wl_event_loop_add_signal(loop, SIGUSR1,
 signal_callback, got_it);
   -   wl_event_loop_dispatch(loop, 0);
   +   assert(source);
   +   assert(wl_event_loop_dispatch(loop, 0) == 0);
  
 
  You shouldn't put code with side effects inside asserts, since it'll be
  compiled out in release mode.

 That's actually standard procedure in the test suite. The test suite
 refuses to work at all, if you compile asserts away. We rely on them
 here, but you are right in general.


 Thanks,
 pq

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] terminal: Handle the window close event.

[Dima Ryazanov]

There may be multiple windows open, so destroy the terminal instead of exiting.

Signed-off-by: Dima Ryazanov d...@gmail.com
---
 clients/terminal.c |9 +
 1 file changed, 9 insertions(+)

diff --git a/clients/terminal.c b/clients/terminal.c
index 25acc81..664df5d 100644
--- a/clients/terminal.c
+++ b/clients/terminal.c
@@ -2069,6 +2069,14 @@ fullscreen_handler(struct window *window, void *data)
window_set_fullscreen(window, !window_is_fullscreen(terminal-window));
 }
 
+static void
+close_handler(struct window *window, void *data)
+{
+   struct terminal *terminal = data;
+
+   terminal_destroy(terminal);
+}
+
 static int
 handle_bound_key(struct terminal *terminal,
 struct input *input, uint32_t sym, uint32_t time)
@@ -2541,6 +2549,7 @@ terminal_create(struct display *display)
window_set_keyboard_focus_handler(terminal-window,
  keyboard_focus_handler);
window_set_fullscreen_handler(terminal-window, fullscreen_handler);
+   window_set_close_handler(terminal-window, close_handler);
 
widget_set_redraw_handler(terminal-widget, redraw_handler);
widget_set_resize_handler(terminal-widget, resize_handler);
-- 
1.7.10.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel