| 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]> |