index.md - sites - public wiki contents of suckless.org
 (HTM) git clone git://git.suckless.org/sites
 (DIR) Log
 (DIR) Files
 (DIR) 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-grabbed.html:
           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 sent
           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 it is
           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 <christopher.lang.256@gmail.com>