index.md - sites - public wiki contents of suckless.org | |
git clone git://git.suckless.org/sites | |
Log | |
Files | |
Refs | |
--- | |
index.md (2674B) | |
--- | |
1 fixmultimon | |
2 =========== | |
3 | |
4 Description | |
5 ----------- | |
6 When the pointer is on an unselected monitor and is not moving, it | |
7 should not interfere what window is selected/focused. | |
8 | |
9 1: | |
10 | |
11 From https://tronche.com/gui/x/xlib/events/input-focus/normal-and-grabb… | |
12 > When the focus moves from window A to window B, A is an inferior of B, | |
13 > and the pointer is in window P, the X server does the following: | |
14 > It generates a FocusOut event on window A... | |
15 > It generates a FocusOut event on each win... | |
16 > It generates a FocusIn event on window B,... | |
17 > If window P is an inferior of window B but window P is not window A or | |
18 > an inferior or ancestor of window A, it generates a FocusIn event on | |
19 > each window below window B, down to and including window P, with the | |
20 > detail member of each XFocusInEvent structure set to NotifyPointer. | |
21 | |
22 If focusmon selects a monitor with no clients then XSetInputFocus is | |
23 called on the root window. Due to the above rules, an FocusIn event is s… | |
24 to the window under the pointer which may be on another monitor. Now a | |
25 window on one monitor is getting our keyboard input but another monitor | |
26 is selected. In this undesirable state, a killclient shortcut (for | |
27 example) will not destroy the window that is accepting input. | |
28 | |
29 We fix this by focusing on the bar window instead of root when an empty | |
30 monitor is selected. Windows on other monitors are not a children of the | |
31 bar window so they will not be focused by a NotifyPointer event. | |
32 | |
33 2: | |
34 | |
35 If a window is moved from the selected monitor to the monitor under the | |
36 pointer and the rearrangement of windows on the second monitor causes a | |
37 different window to be under the pointer, then an enternotify event is | |
38 sent for that window. This causes that window to be focused and the | |
39 second monitor to be selected. If the arrangement on the second monitor | |
40 did not cause the pointer to be under a different window then the | |
41 selected monitor would not change (very unpredictable behaviour!). | |
42 | |
43 We fix this by suppressing all enternotify events at the end of an | |
44 arrange(NULL) call. | |
45 | |
46 Mainline Patch | |
47 -------------- | |
48 | |
49 This patch was originally sent to the hackers mailing list to be included | |
50 in the mainline dwm repo. | |
51 [link](https://lists.suckless.org/hackers/2308/18950.html). | |
52 However, it has not yet been added due to insufficient feedback from | |
53 multi-monitor users and some doubt as to weather this patch follows X | |
54 focus-follow-mouse tradition. | |
55 | |
56 I still believe this patch belongs in the mainline. But in the meantime … | |
57 here to help multi-monitor users and gather more feedback. | |
58 | |
59 Download | |
60 -------- | |
61 * [dwm-fixmultimon-6.4.diff](dwm-fixmultimon-6.4.diff) | |
62 | |
63 Authors | |
64 ------- | |
65 * Christopher Lang <[email protected]> |