On Fri, 02 May 2014 19:22:39 +0100 Neil Roberts <n...@linux.intel.com> wrote:
> 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. Hi, I think creating the socket pair in the client that launches another client and passes it on in WAYLAND_SOCKET could be the key here. This is the lowest-level standard mechanism, as it is implemented in libwayland-client. However, I don't agree with using the new connection to pre-set the stage as you imagined. Doing stuff on a connection and then pretending it is a fresh connection for the new client is tedious like you said. Instead, we could have an "app launcher" protocol extension. The lancher client, e.g. weston-desktop-shell with the panel buttons, creates a socket pair, and passes the server end to the compositor by using this new protocol. But it does not have to stop there. The protocol could also allow things like setting the default output, designating how the new app will be launched, which wl_seat did it, etc. Anything the compositor might see as useful. Also, on which workspace the new app should appear by default. This "app launcher" extension could be a public interface. After all, clients will be able to connect to the socket file, too, so no need to restrict this I guess. As a side-effect, it would also allow launching a client as a different user by using a suitable launcher tool. If the client using the "app launcher" extension is already privileged, there might be a mechanism to pass the authorization on to the new client. (Jumping to another topic here. :-) The hard part will be designing the "app launcher" extension. If it is a public, generic extension to be in the core, it cannot reference xdg_shell or desktop concepts. What things should it have? > 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. Right. Though another option comes to mind, but I'm not sure how good it is. The terminal could ask the compositor to create a unique cookie, e.g. a short string hash, that refers to the terminal's window. The terminal sets the cookie into a known environment variable, which will then pass on to all programs started on the terminal. If the programs find the environment variable set, they could pass it back to the compositor again. That way the compositor knows which window caused a new client to appear, and could do whatever appropriate. If not all programs know how to handle the cookie, you could write a command line launcher tool, which uses the cookie and the "app launcher" extension somehow to achieve the same effect. This cookie mechanism is not intended for authorization at all, and no privileges should ever be granted based on it. It is merely a hint for the compositor to be nicer to the user, like putting the new app on the right output and workspace by default. How do these sound? Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
