Ubuntu 21.04 - Can't interact under window with Wayland

[patdavid]

Hello!
Just wanted to comment that using the released Ubuntu 21.04 install, which defaults to Wayland, I cannot interact with elements under the peek window. Switching to xorg things do work as expected.

[dzintars]

Same on vanilla Wayland (no XWayland/Xorg)

[jocelyn]

I experienced the same issue on Ubuntu 20.04 (GNOME 3.36), 21.04 (GNOME 3.38), or 21.10 (GNOME 40), all with Wayland. I have no trouble with Xorg. I tried other tools that has transparent window on top of others, and they have the same kind of issues. Any idea if a solution could exist, or if Wayland does not allow the wanted behavior?

This issue makes Peek unusable for me on Wayland

[prasket]

I moved from POP_OS (non-wayland) to Debian Bullseye (wayland) am also seeing the same as others using wayland. :(

[willhubs]

Peek was working for me for me perfectly under a new Ubuntu 21.10 install until very recently. Last time I used it was mid November and had zero problems interacting while Peek was overlaying and it recorded the cursor and everything. Today Dec8 I tried to use it again and can not interact with anything under the peek window. Not sure what has changed between then and now, but it broke my ability to do recordings. Peek 1.5.1 Gnome 40.4.0 Wayland mutter 40.5-1ubuntu3~21.10.1

Edit: After restarting the system it is now on 5.13.0-22-generic and working perfectly again.

[cmalard]

@willhubs under Wayland too? :open_mouth: (switched to xorg too for now)

[willhubs]

Sorry, it was under xorg, had switched.

[CrowleyND]

Having the same issue. For some reason, Peek only works with Google Chrome, it's not working with Firefox or any other windows. Any idea about what to do? The only way would be swiching to xorg?

System info: Peek version: 1.5.1+git20211214-1 Ubuntu 22.04 LTS GNOME 42.2 Wayland

[derMart]

May this be related to https://bugzilla.gnome.org/show_bug.cgi?id=774534 ? peek seems to be using https://github.com/phw/peek/blob/6f15b9dbe559ce6f82770717c5b3138d8df943ca/src/ui/application-window.vala#L684 to set its input shape. Notice this comment in bug report above:

so we need to apply the input shape once parent surface is in effective desynchronized mode, which is when it's committed, otherwise the input shape may never be applied if the widget is not using being_paint() / end_paint() to draw on its subsurface, like clutter does.

We do that only for empty input shape as those won't need update when the subsurface is resized, for all other non-empty input shape, the client still has to use begin_paint()/end_paint() for the input shape to be applied.

So a simple begin_paint / end_paint call inside update_input_shape might be a workaround?