Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

focus issue with multiple awesome instances #599

Closed
kdt3rd opened this issue Dec 16, 2015 · 5 comments
Closed

focus issue with multiple awesome instances #599

kdt3rd opened this issue Dec 16, 2015 · 5 comments

Comments

@kdt3rd
Copy link
Contributor

kdt3rd commented Dec 16, 2015

If I run multiple instances of awesome on separate X screens:

DISPLAY=:0.0 awesome &
DISPLAY=:0.1 awesome

it mostly works, except the focus is a little wonky. If there are multiple windows (i.e. multiple terminals) mapped on the current tag of the root window I'm moving into, if I cross one of those windows, then focus is transferred, and the expected instance of awesome gets the key events to manage windows / launch applications. But if there is only one window (or none) - basically so there isn't an enter/leave/enter chain of events (or some other event I don't know of), then the screen the mouse moves into doesn't transfer focus to that window now under the mouse. Additionally, if there are no windows on the currently displayed tag on the newly-entered screen, the hot keys are still applied to the original screen, although I can click on the awesome menu bar and launch an item, at which point focus is where you would expect.

Thinking the last would be the easiest, I tried adding a check in event_handle_enternotify in event.c and regrabbing keys as happened in the mapping notify when the enter notify window is the root window. Apparently I missed something about the internal state of things (or am testing for the wrong thing), as that had no effect. Any clues / docs about what to change, please let me know and I will try it. For the focus problem when there is a window, I suspect something similar where there's a leavenotify but because the other process gets the enternotify since the root window has changed as it's a different screen, there's some state of focus not being updated.

thanks!

@psychon
Copy link
Member

psychon commented Dec 16, 2015

No idea which awesome version you are on, so I will assume awesome 3.5. Could you modify client_focus_refresh() here and replace globalconf.screen->root with XCB_POINTER_ROOT?

Edit: Some docs for xcb_set_input_focus(): http://www.x.org/releases/current/doc/man/man3/xcb_set_input_focus.3.xhtml (just so that I don't have to google again how this constant is called)

@kdt3rd
Copy link
Contributor Author

kdt3rd commented Dec 17, 2015

I apologize, I should have mentioned that I pulled a HEAD tree when I ran into the issue to see if it's already been fixed prior to filing a bug. I will attempt your change and report. If it works, do you want me to submit a pull request (which means I should fork instead of just using anonymous pull), or will you just make the change?

@kdt3rd
Copy link
Contributor Author

kdt3rd commented Dec 17, 2015

so your suggested change seems to have no effect (btw, the value seems to be XCB_INPUT_FOCUS_POINTER_ROOT, not XCB_POINTER_ROOT - the latter does not exist).

what I did after trying this was to modify event.c as per the attached diff
event_hack.zip

you can probably ignore the printfs ;-P

I exposed the client_unfocus. This works like 75%, so it's probably that because there are two instances of awesome, one on each screen, that there is a timing issue, or that I'm just plainly not doing the right thing since I'm only just starting to learn the awesome source code.

@psychon
Copy link
Member

psychon commented Dec 17, 2015

Hm, your patch is a nice idea. Could you remove the code for leavenotify and only force a focus update for the enter notify? Something like the following in event_handle_enternotify should work:

else if (ev->event == globalconf.screen->root) {
    globalconf.focus.need_update = true;
}

(No need to call client_focus_refresh(), that's automatically done at the end of each main loop iteration and no need to call client_focus_update() as that only tells Lua that something got the focus, but doesn't do anything X11-related)
The likely reason why your patch doesn't work is a race between your two awesome instances. If the pointer moves between root windows, the awesome instance that was left tries to set the input focus to "nothing has the focus" and the awesome instance that was entered tries to set the focus to some window. Whichever of the two is slower will win, so either a window is focused or no window is focused.
My suggested change will only make the awesome instance that is entered set the input focus. This would still have both instances "think" that some window has the input focus and show it as focused, but at least the input focus itself (=what happens when you type) should work correctly. If you want, I can also think about a way to have only one window visible as focused.

@kdt3rd
Copy link
Contributor Author

kdt3rd commented Dec 18, 2015

yeah, I tried something like that initially (only refreshing on enter notify), although I had a bunch of other changes I had tried still in there as well which may have caused problems. Let me clean that up, retry and report back - will take a couple days due to work travel.

psychon pushed a commit that referenced this issue Jan 11, 2016
When there are multiple X11 screens (i.e. :0.0 and :0.1) for zaphod mode
style X setups, this triggers a refresh of focus when the instance
running on a particular root receives the mouse

Fixes #599.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants