Re: Thoughts on getting surfaces to appear on the right output
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
Re: Thoughts on getting surfaces to appear on the right output
We solved this under X11 with the startup-notification protocol. Ryan Lortie has been looking at making a DBus-only startup-notification for other platforms like Wayland. Since there's an intersection here, I'm going to CC Ryan and have him provide his thoughts on this, so we don't have duplicate effort and multiple protocols to support across DEs. On Tue, May 6, 2014 at 3:11 AM, Pekka Paalanen ppaala...@gmail.com wrote: 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
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: 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
Re: Thoughts on getting surfaces to appear on the right output
Bill Spitzak spit...@gmail.com 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
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
