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