Click events not reaching applications on external monitor

KrokodileDandy · 2023-03-06 07:42:25

Hi everyone,

The Problem: Mouse input is not transferred to some applications on any external monitor.

Description: This only affects some applications, others work just fine. This also only happens for external monitors, all applications work on my primary (laptop) monitor.

I can't figure out why only some applications on my external screen are affected nor how to solve the issue, so any help in either direction is greatly appreciated!

Additional Information

This is the output of

sudo libinput list-devices

for the mouse I am currently trying to solve the issue with, but the problem also occurs with other click-type inputs like my touchpad buttons:

Device:           USB Optical Mouse
Kernel:           /dev/input/event16
Group:            5
Seat:             seat0, default
Capabilities:     pointer 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      disabled
Nat.scrolling:    disabled
Middle emulation: disabled
Calibration:      n/a
Scroll methods:   button
Click methods:    none
Disable-w-typing: n/a
Disable-w-trackpointing: n/a
Accel profiles:   flat *adaptive
Rotation:         n/a

Running

sudo libinput debug-events

shows me that the clicks are registered, so they seem to only not be able to reach the applications in question.

Edit from 2023-03-09:

I run the Sway compositor with wayland.

Some of the applications which are affected:

Vivaldi Browser
Keepass
Obsidian

All of those applications are in fact using xwayland. I tested this with xwininfo, following this post.

Last edited by KrokodileDandy (2023-03-09 16:24:17)

seth · 2023-03-06 09:13:46

What applications (in case of wayland: xwayland ones?), what's your display server (X11 or wayland, which compositor) and how do you determine that the "Mouse input is not transferred to some applications on any external monitor" (I guess because the application doesn't respond as expected, what what's the expectation - also ties into "what applications")

ewaller · 2023-03-06 15:38:51

And which desktop environment / window manager are you using?

Trilby · 2023-03-06 17:48:26

Based on the OP's previous thread, they are using sway. This is likely an error in the compositor code used to determine which toplevel surface to send the mouse events to as this can be a bit tricky with multiple monitors (converting between screen, surface, subsurface, layount - and scene-graph with wlroots > 0.16 - coordinates can get messy). Given that it's only on some clients, I'd suspect it's either Xwyaland clients and / or clients that have various subsurfaces rather than simple single-toplevel-surface clients. Depending on which of these suspicions is / isn't correct, this may be a sway bug.

A potentially simple test to confirm part of this suspicion would be to position the external screen at the origin (0,0) and the internal screen offset to the right (this can be done with wlr-randr). I'd predict the problem would then occur only on the internal screen while clients on the external screen would get mouse events just fine.

Last edited by Trilby (2023-03-06 20:44:47)

KrokodileDandy · 2023-03-09 16:23:50

Using wlr-randr has the exact effect assumed by Trilby. Is there a way to fix this or do I have to hope for updates from those applications/native wayland support?

I added the following information as an edit to the original post:

I run the Sway compositor with wayland.

Some of the applications which are affected:

Vivaldi Browser
Keepass
Obsidian

All of those applications are in fact using xwayland. I tested this with xwininfo, following this post.

Trilby · 2023-03-09 16:46:08

Are *all* clicks on those application's windows lost, or just certain menus, popups, or other forms of subwindow? In any case this should be reported upstream to the sway developers.

But you can likely work around this quite well as there is no reason for vivaldi or obsidian to run on xwayland, they should run natively under wayland but may need some configuration to do so (e.g., there are notes in the electron page of our wiki which would apply for obsidian).

Keepass I'm not familiar with but I didn't think it had it's own gui ... does it? Or are you using some graphical front end provided by a package other than keepass?

EDIT: FYI:
- https://wiki.archlinux.org/title/Vivald … nd_support
- https://wiki.archlinux.org/title/Wayland#Electron

Last edited by Trilby (2023-03-09 16:56:37)

KrokodileDandy · 2023-03-09 17:31:03

Thank you, the suggested solutions for forcing native Wayland support for Vivaldi and Obsidian work flawlessly.

Just to clarify: That means that some packages on Wayland are still launched with XWayland, as per default configuration, which is why some configuration has to be done. Is there a recommended approach for applications that might not be supported by Wayland yet? For keepass I use the "default" package called keepass which comes up in the ArchWiki. But I now saw that it seems to have stopped being supported in May last year, so I'll adopt a new GUI.

For the ones that don't/didn't work, not a single click is/was transferred to the actual application.

Last edited by KrokodileDandy (2023-03-09 17:34:13)

seth · 2023-03-09 18:14:32

https://github.com/swaywm/sway/issues

Is it really just the mouse? Does keyboard input or output like videos work™ in those clients?

Trilby · 2023-03-09 18:27:53

It looks like there are many related issues on that github tracker. The only "closed" ones are where they were satisfied with the workaround of putting Xwayland windows only on the output at 0,0. That or some closed as "wontfix" as everyone is pointing fingers at someone else to blame (sway / wlroots / xwayland / xorg / individual x-clients).

Last edited by Trilby (2023-03-09 18:38:15)

seth · 2023-03-09 18:42:40

There's notably https://github.com/swaywm/sway/wiki#mou … workspaces / https://github.com/swaywm/sway/issues/4867 that might apply depending on the output configuration.

Trilby · 2023-03-09 18:54:59

I'm a bit baffled about how this is considered an xwayland bug. It is the compositor's job to send events to clients in surface-relative coordinates. Surface-relative coordinates can't be negative; the layout-relative position of that surface is irrelevant. So if xwayland clients are getting negative coordinates for cursor movement events, sway is sending the wrong data to them.

(note: "surface" is roughly equivalent to "window")

EDIT: I just confirmed that sway does in fact only send surface-relative coordinates to clients. So there is no way a negative layout position of a xwayland window could be relevant. But there could likely be an error in the way sway is determining whether or not to send those events to the client based on it's position relative to the cursor. The code for this that applies to xwayalnd clients is at sway/input/cursor.c lines 108-124, and this relies on proper values for layout coordinates for what sway calls "unmanaged surfaces" - and if these coordinates are incorrect (or not yet calculated) this would result in the observed symptoms.

That or, perhaps more likely, the wlr_surface_point_accepts_input function is not returning a true result in that context which would not surprise me at all - relying on that function there seems problematic to me. I'd wager that removing that conditional check and sending the event unconditionally would "fix" this problem. That'd not be the proper long-term fix, but it would confirm that the use of that function is the problem. The wlroots comments on this function specifically note that it doesn't check subsurfaces which might be required for this function to be used in the way it is intended.

If it were my code or patching-project, I'd put some diagnostic logging in that section to record whether or not the wlr_surface_point_accepts conditional passed as well as logging the _sx, _sy values to ensure they actually look like proper surface-relative coordinates (e.g., if you move the mouse very near to the upper-left of a "window", the _sx and _sy values should be small positive numbers).

Last edited by Trilby (2023-03-09 19:42:22)

KrokodileDandy · 2023-03-11 08:28:10

I tested the video output via YouTube in Vivaldi, which seems to work as intended. Webcam works too. The keyboard input also works, for example in Vivaldi and Obsidian.

The xserver issue 899 is actually also true for my setup and seems to have been the problem. I tested this with Keepass, which doesn't recognize my mouse input on the external screen. Using wlr-randr I moved the external screen "below" my laptop screen for a positive coordinate and it worked! According to this post, they won't fix the issue with the negative coordinates, so I'll setup my workspace with the external monitor being the source monitor and my laptop being "below" it.

Slightly related and I don't know whether I should open a new topic about this: After having changed the Electron configuration file, Obsidian now works on the second screen as intended (see above). However, I noticed the drag-and-drop feature stopped working (on either screen). Is this also related to the communication between the application and the compositor? I can click and drag a tab inside Obsidian and when I hover over an area the application registers this and shows me the preview of how the new tab would affect the layout of my tabs. However, when I let go, the tab doesn't "snap" into the space anymore. Running obsidian with

obsidian --ozone-platform-hint=x11

results in the drag-and-drop working again, so it is somehow related again to the xwayland vs wayland issue.

seth · 2023-03-11 13:42:50

I noticed the drag-and-drop feature stopped working

Is this limited to obsidian tabs?
It sees weird that dnd would work w/ xwayland but not straight up wayland, so this might be down to the WM behavior of (the tiling) sway?

KrokodileDandy · 2023-03-12 07:09:40

This seems to be limited to Obsidian tabs, as drag and drop with for example sidebar icons works as expected.

I also noticed that in Vivaldi the drag and drop of tabs now is also buggy. For example, when I want to create a new tab stack via dnd, the tab becomes a new window instead. Moving it back into the old window merges the two tabs as expected, but only if I drag it to the left of the original tab; on the right side it refuses to work. However, when I switch Vivaldi back to XWayland (source), the bug remains. This is why I am not sure this was introduced by switching to Wayland, even though the bug didn't exist a week ago.

What does WM mean?

seth · 2023-03-12 07:26:44

WindowManager (sway, X11 phrase because WM and displayserver/compositor were not the same)
Did you also revently update vivaldi?

KrokodileDandy · 2023-03-12 08:01:48

Ah, ok, thank you!

No, I did not update Vivaldi recently and the bug appeared way after I did the last one.

seth · 2023-03-12 11:38:57

Does vivaldi behave the same w/ weston?

Arch Linux

#1 2023-03-06 07:42:25

Click events not reaching applications on external monitor

Additional Information

#2 2023-03-06 09:13:46

Re: Click events not reaching applications on external monitor

#3 2023-03-06 15:38:51

Re: Click events not reaching applications on external monitor

#4 2023-03-06 17:48:26

Re: Click events not reaching applications on external monitor

#5 2023-03-09 16:23:50

Re: Click events not reaching applications on external monitor

#6 2023-03-09 16:46:08

Re: Click events not reaching applications on external monitor

#7 2023-03-09 17:31:03

Re: Click events not reaching applications on external monitor

#8 2023-03-09 18:14:32

Re: Click events not reaching applications on external monitor

#9 2023-03-09 18:27:53

Re: Click events not reaching applications on external monitor

#10 2023-03-09 18:42:40

Re: Click events not reaching applications on external monitor

#11 2023-03-09 18:54:59

Re: Click events not reaching applications on external monitor

#12 2023-03-11 08:28:10

Re: Click events not reaching applications on external monitor

#13 2023-03-11 13:42:50

Re: Click events not reaching applications on external monitor

#14 2023-03-12 07:09:40

Re: Click events not reaching applications on external monitor

#15 2023-03-12 07:26:44

Re: Click events not reaching applications on external monitor

#16 2023-03-12 08:01:48

Re: Click events not reaching applications on external monitor

#17 2023-03-12 11:38:57

Re: Click events not reaching applications on external monitor

Board footer