In labwc, we have had trouble with XWayland windows using the Globally
Active input model (see wlr_xwayland_icccm_input_model()). Under
traditional X11, these windows do not expect to be given focus directly
by the window manager; rather, the WM sends them a WM_TAKE_FOCUS message
prompting the client to take focus voluntarily.
Currently, these clients are difficult to support with wlroots, because
wlr_xwayland_surface_activate() assumes the client window will always
accept the keyboard focus after being sent WM_TAKE_FOCUS. Some Globally
Active client windows (e.g. panels/toolbars) don't want to be focused.
It's useless at best to focus them, and might even make them misbehave.
Others do need keyboard focus to be functional -- and there doesn't seem
to be any reliable way to know this in advance.
Adding wlr_xwayland_surface_offer_focus() allows the compositor to send
WM_TAKE_FOCUS to a client window supporting it and then see whether the
client accepts or ignores the offer. If it accepts, the surface will emit
the focus_in signal notifying the compositor that it has received focus.
This is entirely opt-in. A compositor that doesn't want to use the new
function can continue to call wlr_xwayland_surface_activate() directly
just as before.
Currently _NET_WM_STATE is updated in xwm_focus_window() but
_NET_ACTIVE_WINDOW is updated in xwm_surface_activate(). In some cases
(for example, client-initiated focus changes) the two properties can get
out of sync.
Factor out a new function which updates both properties in sync.
Adjust the logic in xwm_handle_focus_in() to call either
xwm_focus_window() or xwm_set_focused_window(), or neither, as
appropriate.
From the event description:
This event indicates that the output power management mode control is no
longer valid. This can happen for a number of reasons, including:
<...>
- The output disappeared
This swaps the argument order of wlr_surface_accepts_touch() and
wlr_surface_accepts_tablet_v2(), putting the wlr_surface argument first
as should be the case for functions namespaced with wlr_surface_*.
We were relying on the fact that we wouldn't paint anything on top
of the black background in the region of a black rect. However
when fractional scaling is used the repaint region might get
expanded to nearby pixels by scale_output_damage(). As a result
the neighbour scene nodes might leak into the skipped black rect's
region.
Avoid this by using this optimization for bottom-most black rects
only when fractional scaling is used.
References: https://github.com/swaywm/sway/issues/8233
