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
Comments
No idea which awesome version you are on, so I will assume awesome 3.5. Could you modify Edit: Some docs for |
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? |
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 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. |
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 else if (ev->event == globalconf.screen->root) {
globalconf.focus.need_update = true;
} (No need to call |
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. |
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.
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!
The text was updated successfully, but these errors were encountered: