search

djpohly / dwl

dwm for Wayland - ARCHIVE: development has moved to Codeberg
https://codeberg.org/dwl/dwl
Other
1.94k stars 284 forks source link

Multi-Monitor X11 app mouse input failure [WORKAROUND] #269

Open Manfred-Knick opened 2 years ago

Manfred-Knick commented 2 years ago

Info

dwl's commit: dwl 0.3.1-HEAD-af12e77 wlroots version: 0.15.1

HW: GeForce GTX 1070 Ti (rev a1) x11-drivers/nvidia-drivers-515.57

Description

Running a 2 x 2 = 4 Monitor setup: . . . . . DP-0 | HDMI-0 . . . . . -----+------- . . . . . DP-2 | DP-4 I encountered working keyboard input on all, but non-working mouse input on all but the "first" monitor for xterm and xfe.

Setup 1: wlr-randr --output HDMI-A-1 --preferred --pos 0,0 wlr-randr --output DP-1 --preferred --pos -2560,0 wlr-randr --output DP-2 --preferred --pos -2560,1440 wlr-randr --output DP-3 --preferred --pos 0,1440

Investigating (*) about the queue dwl / wlroots / wayland / xwayland / X11, I finally suspected the handling of relative placement commands with negative indices.

Workaround

Re-structure to positive indices only:

Setup 2: wlr-randr --output DP-1 --pos 0,0 wlr-randr --output HDMI-A-1 --pos 2560,0 wlr-randr --output DP-2 --pos 0,1440 wlr-randr --output DP-3 --pos 2560,1440

This indeed "solved" the issue for me: xterm, XFE and others got their mouse input delivered and reacted as to be expected.

Disclaimer

I am not able to differentiate in which of the component layers involved the bug resides. It need not be dwl itself which is to blame.

Thanks

(') Grateful for initial background reading - still helpful: (1) "Modular Wayland compositors with wlroots" [ https://l.sr.ht/jAFC.pdf ] (2) "Input handling in wlroots" [ https://drewdevault.com/2018/07/17/Input-handling-in-wlroots.html ]

Manfred-Knick commented 2 years ago

For sake of completeness: The "native" linear setup found by dwl is . . . . . [ HDMI-0 | DP-0 | DP-2 | DP-4 ] and naturally does not suffer above mouse input problems.

These only arise after calling any wlr-randr re-ordering with negative coordinates involved.

Request for examination: Can anybody with a NVidia/Nouveau, Intel or AMD setup check against these findings, please? Even a two-monitor setup would already be sufficient to test.

Thanks in advance!

sevz17 commented 2 years ago

Can you check this in sway, please?

Manfred-Knick commented 2 years ago

Quick test@night ...

EDIT: re-install sway / re-test :

Summary: --> same problems as below dwl

Details:

"native linear setup": . . . xterm mouse input works on all monitors

"Setup 1": . . . xterm mouse input works on HDMI-0 and DP-4 <-- "0 or positive offset" . . . xterm mouse input fails on DP-0 and DP-2 <-- "contains at least one negative"

"Setup 2" . . . xterm mouse input works on all monitors <-- "only 0 or positive offset"

? wlr-randr --> wlroots ?

HTH Kind regards

sevz17 commented 2 years ago

If this happens either in sway and dwl, I think this is a wlroots bug, @emersion am I wrong?

Manfred-Knick commented 2 years ago

Please note: As mentioned in my OP, building current dwl still requires wlroots version: 0.15.1 and fails against current wlroots.

Correct myself: works with current wlr-randr.

NB-wo commented 1 year ago

i may have the same problem. when i use two-monitor and set one above the other(also with negative coordinates),i open >=2 windows in tiled(in the monitor that not the "first"), and then these windows don't tiled normally（i don‘t know how to discribe，it is strange and can’t use）.But in the "first" monitor it is normal.And when i use the "The 'native' linear setup", everything is ok.btw, i use intel gpu.