Thoughts on getting surfaces to appear on the right output

[Neil Roberts]

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