Re: Thoughts on getting surfaces to appear on the right output
On 05/02/2014 03:49 PM, Neil Roberts wrote: 1. It would seem more useful for the desktop shell to send some info about how the client was launched in environment variables. Yes, maybe it would be cleaner to agree on some protocol for the parent process to send the information directly to the child. I'm not sure about using environment variables though because they tend to be inherited. For example if you used the desktop shell to launch a terminal then all clients that that terminal launched would end up with the same environment variables. Good point. Yes that would screw up. I was thinking the lack of environment variables would indicate a launch from a terminal, but unless all terminal clients cleared all the Wayland environment variables this would not work. And I don't think it should be the terminal client's responsibility to know the entire current set of Wayland environment variables and remove them. I think that is enough reason to give up on the environment variable idea. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Thoughts on getting surfaces to appear on the right output
Bill Spitzak writes: > 1. It would seem more useful for the desktop shell to send some info > about how the client was launched in environment variables. Yes, maybe it would be cleaner to agree on some protocol for the parent process to send the information directly to the child. I'm not sure about using environment variables though because they tend to be inherited. For example if you used the desktop shell to launch a terminal then all clients that that terminal launched would end up with the same environment variables. > 2. If the desktop shell creates the socket, there is no need for it to > "send commands" on it. Instead it can directly manipulate the local > end to have the results of those commands. The desktop shell is also a client in a separate process so it can't directly manipulate the compositor's view of the new client without some sort of protocol. Regards, - Neil ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Thoughts on getting surfaces to appear on the right output
Two comments on the proposal: 1. It would seem more useful for the desktop shell to send some info about how the client was launched in environment variables. The client may want to do other reactions besides just placing it's window, and this will work for clients that do not want to use the socket (such as a client that wraps a launch of a remote client?). 2. If the desktop shell creates the socket, there is no need for it to "send commands" on it. Instead it can directly manipulate the local end to have the results of those commands. I also want to rant about "getting surfaces to appear on the right output" which is currently impossible on Wayland, even if the above fixes are added: The apps I am working on control multiple-window clients on multiple outputs. There is at least one full-screen window, and then several large (but not full-screen) windows arranged on the remaining outputs. Sometimes all outputs are filled with fullscreen windows, and also sometimes some of these are maximized instead of fullscreen (to make it possible to hit the titlebar button to toggle screen-filling on/off, and also because of important information that is displayed in the titlebar (that may be a bad idea, but it is there...). See Nuke for an example, if users have multiple outputs they usually put a viewer on one output and put all the controls (a big tiled window) on the other output. Most clients have a significant difference between the outputs (only one is calibrated, or one is the big-screen on the wall that their customers see, etc). In any case our users expect to get exactly the same layout they arrived at before when they run the software again. Wayland is not delivering this, instead every window lands on the same output. Even if it tried to intelligently place them on "unused" outputs it is not going to work, we had some window managers that did this and they would randomly swap which window was on which output, and that is definately not what the user wants. I know it is rejected, but I also have to point out that EVERY OTHER SYSTEM uses an x,y position in a huge plane where all the outputs are mapped to non-overlapping rectangles to determine which output a window appears on. This x,y position can both be read and set by a client, and the client can then save it in a configuration file as two numbers per window. Wayland is breaking this: first we do not have the level of control we have in other systems, but much more serious is we do not have cross-platform savable configurations (and many of our users actually do reboot to swap between Linux and OS/X). On 05/02/2014 11:22 AM, Neil Roberts wrote: launches. To do this I was thinking that maybe desktop-shell could make a connection to the compositor on behalf of the client, call a request to set the default output and then pass the socket down to client using the existing WAYLAND_SOCKET mechanism. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Thoughts on getting surfaces to appear on the right output
Hi, Currently Weston has a problem that it always puts new surfaces on the same output as the one the first pointer is in. I guess the idea is that most of the time surfaces are created as a result of mouse events and there is usually only one pointer so it works most of the time. However of course this doesn't work if a surface is created by a touch event, a keyboard event or an event from a second pointer. The problem is mentioned in the following bug report: https://bugs.freedesktop.org/show_bug.cgi?id=73715 I guess ideally you want the client to explicitly say what output new surfaces should appear on because only the client knows which input event caused the new surface to be created. We already have xdg_shell.set_output which the client could use for this purpose. It doesn't look like Weston takes that chosen output into account if the surface is not fullscreen or maximised, but perhaps we could change it so that it does? This isn't a complete solution however because when the client first connects it doesn't know what event caused its process to be executed so it doesn't know which output to put itself on. This is the case when panel buttons are used to launch an application from desktop-shell. I was thinking that maybe we need a request that desktop-shell can make to specify a default output for new surfaces from the clients that it launches. To do this I was thinking that maybe desktop-shell could make a connection to the compositor on behalf of the client, call a request to set the default output and then pass the socket down to client using the existing WAYLAND_SOCKET mechanism. That would be an unusual use of WAYLAND_SOCKET because in the other cases the socket that is passed down is created with socketpair and is not first used for any communication. This would have the effect that wl_display_connect_to_fd is called twice on a connected socket. However, it doesn't look like any data is sent or any negotiation is done when that is called so it might not be a problem. Doing requests on the connection before passing it down might cause the resource ID numbers to get out of sync. However I was thinking that if the parent process is careful to destroy any resources that it creates before forking the child and if the Wayland protocol aggressively reuses IDs then it might reset back to zero anyway and it would just work. I was going to experiment with adding this request as a Weston-specific extension unless someone points out why it won't work. However, I think this probably shouldn't be Weston-specific because normal clients may also want to launch child clients in response to an input event and they too will want to do something similar. This approach wouldn't help for something like launching clients from a terminal window because obviously bash isn't going to do this trick before forking. As a fallback perhaps the positioning mechanism should be that the surface will appear on the last output that received *any* input event instead of where one of the pointers is. It's probably relatively safe to assume that a new surface is related to last input event. You could argue that doing that alone would be enough to fix the problem and we don't need to bother with the new request. However I don't think it would be very robust in cases where the new application is slow to start and there are multiple seats. If someone launches LibreOffice on their seat you don't want the surface to appear on someone else's seat just because it took a while to start and the other person had clicked a button in the meantime. Any thoughts? Regards, - Neil ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: Change wl_surface.damage to be in buffer coordinates.
Bump. I also just added this to the bug-tracker: https://bugs.freedesktop.org/show_bug.cgi?id=78190 --Jason Ekstrand On Thu, Feb 27, 2014 at 12:37 AM, Pekka Paalanen wrote: > On Wed, 26 Feb 2014 21:13:16 -0600 > Jason Ekstrand wrote: > > > Technically, wl_surface.damage is supposed to be called between > > wl_surface.attach and wl_surface.commit. However, I think Weston is > fairly > > forgiving on this point and it might work. > > The order between damage, attach, etc. must be irrelevant, as long > as commit is the last request. This became when we added the commit > request. If there is wording in the spec saying otherwise, I suggest it > should be fixed. > > The commit request was introduced at 0.95.0-40-g3962402, which is > before 1.0. From the very beginning the idea was to allow free > ordering, and if a compositor properly implements the double-buffered > state mechanism, the ordering is automatically free. > > > Thanks, > pq > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: New to Wayland, Need suggestion on a starting point
You could also go after this one: https://bugs.freedesktop.org/show_bug.cgi?id=77769 It shouldn't be too bad if you just follow along with what's done for mouse support. --Jason Ekstrand On Fri, May 2, 2014 at 7:08 AM, Pekka Paalanen wrote: > On Fri, 02 May 2014 17:11:34 +0530 > Srivardhan wrote: > > > Hi All, > > > > > > > > My name is Srivardhan Hebbar, and I'm active developer since 2008, > working > > for Samsung now. > > > > > > > > I am newbie FOSS developer and new to the world of Wayland. I want to > > contribute to this project and want to start with few simpler > contributions > > to understand the code better. > > > > > > > > I have looked into Wayland and Weston modules to some extent. Have been > able > > to build and execute test cases. > > > > > > > > It would be very helpful for me if I can get some > > suggestions/recommendations on which is a simpler module to start with. > > Hi, > > here are some pointers: > > http://lists.freedesktop.org/archives/wayland-devel/2014-April/thread.html#14220 > http://lists.freedesktop.org/archives/wayland-devel/2014-April/014121.html > > > Thanks, > pq > ___ > 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 weston v2] screen-share: Allow fullscreen shell command to be configured
Yeah, this looks better.
Reviewed-by: Jason Ekstrand
On Fri, May 2, 2014 at 4:01 AM, Andrew Wedgbury wrote:
> I've updated this based on comments, simplifying the command handling.
>
> Currently the screen-share module uses a hard-coded command to start the
> fullscreen shell server. This patch causes the module to read the command
> from
> the weston config file (from the "command" key in the "screen-share"
> section).
> The default value remains the same (i.e. to run weston with the RDP
> backend and
> fullscreen shell), but is now located in the weston config file.
>
> As well as allowing the arguments to the fullscreen shell server to be
> changed,
> this also permits an alternative fullscreen shell server to be used if
> required,
> without needing to recompile. Since the command is run as the user running
> weston, this should not pose any additional security risk.
>
> Signed-off-by: Andrew Wedgbury
> ---
> src/screen-share.c | 44 ++--
> weston.ini.in | 3 +++
> 2 files changed, 33 insertions(+), 14 deletions(-)
>
> diff --git a/src/screen-share.c b/src/screen-share.c
> index 6f60b81..f9dcba1 100644
> --- a/src/screen-share.c
> +++ b/src/screen-share.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -101,6 +102,11 @@ struct ss_shm_buffer {
> pixman_image_t *pm_image;
> };
>
> +struct screen_share {
> + struct weston_compositor *compositor;
> + char *command;
> +};
> +
> static void
> ss_seat_handle_pointer_enter(void *data, struct wl_pointer *pointer,
> uint32_t serial, struct wl_surface *surface,
> @@ -982,13 +988,18 @@ shared_output_destroy(struct shared_output *so)
> }
>
> static struct shared_output *
> -weston_output_share(struct weston_output *output,
> - const char *path, char *const argv[])
> +weston_output_share(struct weston_output *output, const char* command)
> {
> int sv[2];
> char str[32];
> pid_t pid;
> sigset_t allsigs;
> + char *const argv[] = {
> + "/bin/sh",
> + "-c",
> + (char*)command,
> + NULL
> + };
>
> if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0, sv) < 0) {
> weston_log("weston_output_share: socketpair failed: %m\n");
> @@ -1025,7 +1036,7 @@ weston_output_share(struct weston_output *output,
> snprintf(str, sizeof str, "%d", sv[1]);
> setenv("WAYLAND_SERVER_SOCKET", str, 1);
>
> - execv(path, argv);
> + execv(argv[0], argv);
> weston_log("weston_output_share: exec failed: %m\n");
> abort();
> } else {
> @@ -1056,7 +1067,7 @@ share_output_binding(struct weston_seat *seat,
> uint32_t time, uint32_t key,
> void *data)
> {
> struct weston_output *output;
> - const char *path = BINDIR "/weston";
> + struct screen_share *ss = data;
>
> if (!seat->pointer) {
> weston_log("Cannot pick output: Seat does not have
> pointer\n");
> @@ -1071,23 +1082,28 @@ share_output_binding(struct weston_seat *seat,
> uint32_t time, uint32_t key,
> return;
> }
>
> - char *const argv[] = {
> - "weston",
> - "--backend=rdp-backend.so",
> - "--shell=fullscreen-shell.so",
> - "--no-clients-resize",
> - NULL
> - };
> -
> - weston_output_share(output, path, argv);
> + weston_output_share(output, ss->command);
> }
>
> WL_EXPORT int
> module_init(struct weston_compositor *compositor,
> int *argc, char *argv[])
> {
> + struct screen_share *ss;
> + struct weston_config_section *section;
> +
> + ss = zalloc(sizeof *ss);
> + if (ss == NULL)
> + return -1;
> + ss->compositor = compositor;
> +
> + section = weston_config_get_section(compositor->config,
> "screen-share",
> + NULL, NULL);
> +
> + weston_config_section_get_string(section, "command", &ss->command,
> "");
> +
> weston_compositor_add_key_binding(compositor, KEY_S,
> MODIFIER_CTRL | MODIFIER_ALT,
> - share_output_binding,
> compositor);
> + share_output_binding, ss);
> return 0;
> }
> diff --git a/weston.ini.in b/weston.ini.in
> index 2c39177..1f216a7 100644
> --- a/weston.ini.in
> +++ b/weston.ini.in
> @@ -65,3 +65,6 @@ path=@libexecdir@/weston-keyboard
> #constant_accel_factor = 50
> #min_accel_factor = 0.16
> #max_accel_factor = 1.0
> +
> +[screen-share]
> +command=@bindir@/weston --backend=rdp-backend.so
> --shell=fullscreen-shell.so --no-clients-resize
> --
> 1.9.2
>
> ___
> wayland-devel mailing list
Re: New to Wayland, Need suggestion on a starting point
On Fri, 02 May 2014 17:11:34 +0530 Srivardhan wrote: > Hi All, > > > > My name is Srivardhan Hebbar, and I'm active developer since 2008, working > for Samsung now. > > > > I am newbie FOSS developer and new to the world of Wayland. I want to > contribute to this project and want to start with few simpler contributions > to understand the code better. > > > > I have looked into Wayland and Weston modules to some extent. Have been able > to build and execute test cases. > > > > It would be very helpful for me if I can get some > suggestions/recommendations on which is a simpler module to start with. Hi, here are some pointers: http://lists.freedesktop.org/archives/wayland-devel/2014-April/thread.html#14220 http://lists.freedesktop.org/archives/wayland-devel/2014-April/014121.html Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
New to Wayland, Need suggestion on a starting point
Hi All, My name is Srivardhan Hebbar, and I'm active developer since 2008, working for Samsung now. I am newbie FOSS developer and new to the world of Wayland. I want to contribute to this project and want to start with few simpler contributions to understand the code better. I have looked into Wayland and Weston modules to some extent. Have been able to build and execute test cases. It would be very helpful for me if I can get some suggestions/recommendations on which is a simpler module to start with. Thank-you, Hebbar http://www.samsung.net/pt_images/C10/securityimage/MSI_20120810083141569.gif ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston v2] screen-share: Allow fullscreen shell command to be configured
I've updated this based on comments, simplifying the command handling.
Currently the screen-share module uses a hard-coded command to start the
fullscreen shell server. This patch causes the module to read the command from
the weston config file (from the "command" key in the "screen-share" section).
The default value remains the same (i.e. to run weston with the RDP backend and
fullscreen shell), but is now located in the weston config file.
As well as allowing the arguments to the fullscreen shell server to be changed,
this also permits an alternative fullscreen shell server to be used if required,
without needing to recompile. Since the command is run as the user running
weston, this should not pose any additional security risk.
Signed-off-by: Andrew Wedgbury
---
src/screen-share.c | 44 ++--
weston.ini.in | 3 +++
2 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/src/screen-share.c b/src/screen-share.c
index 6f60b81..f9dcba1 100644
--- a/src/screen-share.c
+++ b/src/screen-share.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
@@ -101,6 +102,11 @@ struct ss_shm_buffer {
pixman_image_t *pm_image;
};
+struct screen_share {
+ struct weston_compositor *compositor;
+ char *command;
+};
+
static void
ss_seat_handle_pointer_enter(void *data, struct wl_pointer *pointer,
uint32_t serial, struct wl_surface *surface,
@@ -982,13 +988,18 @@ shared_output_destroy(struct shared_output *so)
}
static struct shared_output *
-weston_output_share(struct weston_output *output,
- const char *path, char *const argv[])
+weston_output_share(struct weston_output *output, const char* command)
{
int sv[2];
char str[32];
pid_t pid;
sigset_t allsigs;
+ char *const argv[] = {
+ "/bin/sh",
+ "-c",
+ (char*)command,
+ NULL
+ };
if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0, sv) < 0) {
weston_log("weston_output_share: socketpair failed: %m\n");
@@ -1025,7 +1036,7 @@ weston_output_share(struct weston_output *output,
snprintf(str, sizeof str, "%d", sv[1]);
setenv("WAYLAND_SERVER_SOCKET", str, 1);
- execv(path, argv);
+ execv(argv[0], argv);
weston_log("weston_output_share: exec failed: %m\n");
abort();
} else {
@@ -1056,7 +1067,7 @@ share_output_binding(struct weston_seat *seat, uint32_t
time, uint32_t key,
void *data)
{
struct weston_output *output;
- const char *path = BINDIR "/weston";
+ struct screen_share *ss = data;
if (!seat->pointer) {
weston_log("Cannot pick output: Seat does not have pointer\n");
@@ -1071,23 +1082,28 @@ share_output_binding(struct weston_seat *seat, uint32_t
time, uint32_t key,
return;
}
- char *const argv[] = {
- "weston",
- "--backend=rdp-backend.so",
- "--shell=fullscreen-shell.so",
- "--no-clients-resize",
- NULL
- };
-
- weston_output_share(output, path, argv);
+ weston_output_share(output, ss->command);
}
WL_EXPORT int
module_init(struct weston_compositor *compositor,
int *argc, char *argv[])
{
+ struct screen_share *ss;
+ struct weston_config_section *section;
+
+ ss = zalloc(sizeof *ss);
+ if (ss == NULL)
+ return -1;
+ ss->compositor = compositor;
+
+ section = weston_config_get_section(compositor->config, "screen-share",
+ NULL, NULL);
+
+ weston_config_section_get_string(section, "command", &ss->command, "");
+
weston_compositor_add_key_binding(compositor, KEY_S,
MODIFIER_CTRL | MODIFIER_ALT,
- share_output_binding, compositor);
+ share_output_binding, ss);
return 0;
}
diff --git a/weston.ini.in b/weston.ini.in
index 2c39177..1f216a7 100644
--- a/weston.ini.in
+++ b/weston.ini.in
@@ -65,3 +65,6 @@ path=@libexecdir@/weston-keyboard
#constant_accel_factor = 50
#min_accel_factor = 0.16
#max_accel_factor = 1.0
+
+[screen-share]
+command=@bindir@/weston --backend=rdp-backend.so --shell=fullscreen-shell.so
--no-clients-resize
--
1.9.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] screen-share: Allow fullscreen shell command to be configured
Hi Jason,
On Thu, 1 May 2014, Jason Ekstrand wrote:
On Thu, May 1, 2014 at 9:00 AM, Andrew Wedgbury
wrote:
Currently the screen-share module uses a hard-coded command to start the
fullscreen shell server. This patch causes the module to read the command
from
the weston config file (from the "command" key in the "screen-share"
section).
The default value remains the same (i.e. to run weston with the RDP
backend and
fullscreen shell), but is now located in the weston config file.
As well as allowing the arguments to the fullscreen shell server to be
changed,
this also permits an alternative fullscreen shell server to be used if
required,
without needing to recompile. Since the command is run as the user running
weston, this should not pose any additional security risk.
---
src/screen-share.c | 62
++
weston.ini.in | 3 +++
2 files changed, 51 insertions(+), 14 deletions(-)
diff --git a/src/screen-share.c b/src/screen-share.c
index 6f60b81..6e9a14f 100644
--- a/src/screen-share.c
+++ b/src/screen-share.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
@@ -101,6 +102,11 @@ struct ss_shm_buffer {
pixman_image_t *pm_image;
};
+struct screen_share {
+ struct weston_compositor *compositor;
+ char *command;
+};
+
static void
ss_seat_handle_pointer_enter(void *data, struct wl_pointer *pointer,
uint32_t serial, struct wl_surface *surface,
@@ -982,13 +988,15 @@ shared_output_destroy(struct shared_output *so)
}
static struct shared_output *
-weston_output_share(struct weston_output *output,
- const char *path, char *const argv[])
+weston_output_share(struct weston_output *output, const char* command)
{
int sv[2];
char str[32];
pid_t pid;
sigset_t allsigs;
+ struct wl_array args;
+ char **argv;
+ char *start, *p, **ps;
if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0, sv) < 0) {
weston_log("weston_output_share: socketpair failed:
%m\n");
@@ -1025,7 +1033,28 @@ weston_output_share(struct weston_output *output,
snprintf(str, sizeof str, "%d", sv[1]);
setenv("WAYLAND_SERVER_SOCKET", str, 1);
- execv(path, argv);
+ wl_array_init(&args);
+ start = zalloc(strlen(command)+1);
+ if (start == 0)
+ return NULL;
+ strcpy(start, command);
+ while (*start) {
+ for (p = start; *p && !isspace(*p); p++)
+ ;
+
+ ps = wl_array_add(&args, sizeof *ps);
+ *ps = start;
+
+ while (*p && isspace(*p))
+ *p++ = '\0';
+
+ start = p;
+ }
+ ps = wl_array_add(&args, sizeof *ps);
+ *ps = NULL;
+
+ argv = args.data;
+ execv(argv[0], argv);
weston_log("weston_output_share: exec failed: %m\n");
abort();
} else {
@@ -1056,7 +1085,7 @@ share_output_binding(struct weston_seat *seat,
uint32_t time, uint32_t key,
void *data)
{
struct weston_output *output;
- const char *path = BINDIR "/weston";
+ struct screen_share *ss = data;
if (!seat->pointer) {
weston_log("Cannot pick output: Seat does not have
pointer\n");
@@ -1071,23 +1100,28 @@ share_output_binding(struct weston_seat *seat,
uint32_t time, uint32_t key,
return;
}
- char *const argv[] = {
- "weston",
- "--backend=rdp-backend.so",
- "--shell=fullscreen-shell.so",
- "--no-clients-resize",
- NULL
- };
-
- weston_output_share(output, path, argv);
+ weston_output_share(output, ss->command);
Why are we doing our own command parsing? Why not just run "sh -c command"
instead of doing our own command-line parsing? Then we could just do:
char *const argv[] = {
"/bin/sh",
"-c",
command,
NULL
};
It's much simpler and would allow for proper quoting etc. Is there a good
reason why we shouldn't do
