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

Keyboard shortcuts on login don't work until a window is opened #148

Closed
DanielVukelich opened this Issue Nov 5, 2014 · 14 comments

Comments

Projects
None yet
5 participants
@DanielVukelich

My computer has a fresh install of JWM from the Arch official repository.

After logging in, I find that when I try to use any of my keyboard shortcuts to do things like open windows or switch desktops, none of them work. Only when I have opened the JWM root menu by clicking and then selected some program from my menu can I now use shortcuts. If I open the root menu but do not click on any programs contained in it, my shortcuts will not work. Once I have opened this first window from the menu, I can close it and continue to use my keyboard shortcuts.

@bbidulock

This comment has been minimized.

Show comment
Hide comment
@bbidulock

bbidulock Nov 5, 2014

Contributor

Try installing jwm-git from the AUR and see if you have the same problem.

Contributor

bbidulock commented Nov 5, 2014

Try installing jwm-git from the AUR and see if you have the same problem.

@DanielVukelich

This comment has been minimized.

Show comment
Hide comment
@DanielVukelich

DanielVukelich Nov 5, 2014

I can confirm that the problem remains when using jwm-git from the AUR

I can confirm that the problem remains when using jwm-git from the AUR

@bbidulock

This comment has been minimized.

Show comment
Hide comment
@bbidulock

bbidulock Nov 5, 2014

Contributor

Works fine for me without opening a root menu. Did you try the -p option to check your configuration file, or try a dead simple configuration file?

Contributor

bbidulock commented Nov 5, 2014

Works fine for me without opening a root menu. Did you try the -p option to check your configuration file, or try a dead simple configuration file?

@DanielVukelich

This comment has been minimized.

Show comment
Hide comment
@DanielVukelich

DanielVukelich Nov 5, 2014

My config file passes the jwm -p check without error, and even when using the default config file in /etc/system.jwmrc the problem remains.

My config file passes the jwm -p check without error, and even when using the default config file in /etc/system.jwmrc the problem remains.

@bbidulock

This comment has been minimized.

Show comment
Hide comment
@bbidulock

bbidulock Nov 5, 2014

Contributor

Hmmm. Works for me on i686, x86_64, Intel and AMD. I'm sorry but I cannot recreate. Maybe Joe or someone else can help further. Sorry.

Contributor

bbidulock commented Nov 5, 2014

Hmmm. Works for me on i686, x86_64, Intel and AMD. I'm sorry but I cannot recreate. Maybe Joe or someone else can help further. Sorry.

@ml-

This comment has been minimized.

Show comment
Hide comment
@ml-

ml- Nov 5, 2014

Contributor

This is probably caused by the Xorg keyboard configuration.
I've noticed this behavior with key="Escape" which didn't really work because of the option caps:swapescape.

Try keybinds using the keycode="" instead of key="".

Contributor

ml- commented Nov 5, 2014

This is probably caused by the Xorg keyboard configuration.
I've noticed this behavior with key="Escape" which didn't really work because of the option caps:swapescape.

Try keybinds using the keycode="" instead of key="".

@DanielVukelich

This comment has been minimized.

Show comment
Hide comment
@DanielVukelich

DanielVukelich Nov 5, 2014

I tried binding through keycodes and confirmed that even when using keycode="" the menu will not show until a window is opened. It does not make any difference if the keycode is masked with Alt, Ctrl, or Super or if it is not masked at all.

I tried binding through keycodes and confirmed that even when using keycode="" the menu will not show until a window is opened. It does not make any difference if the keycode is masked with Alt, Ctrl, or Super or if it is not masked at all.

@technosaurus

This comment has been minimized.

Show comment
Hide comment
@technosaurus

technosaurus Nov 6, 2014

Contributor

It may be helpful to know what login manager and xserver you are using. Its possible that the login manager is staying active and capturing keys or the xserver isn't passing them to jwm. You can try an alternate login manager like http://galos.no-ip.org/xlm or xserver such as Xvesa or xfbdev.

Contributor

technosaurus commented Nov 6, 2014

It may be helpful to know what login manager and xserver you are using. Its possible that the login manager is staying active and capturing keys or the xserver isn't passing them to jwm. You can try an alternate login manager like http://galos.no-ip.org/xlm or xserver such as Xvesa or xfbdev.

@DanielVukelich

This comment has been minimized.

Show comment
Hide comment
@DanielVukelich

DanielVukelich Nov 6, 2014

Thanks technosaurus, changing from LXDM to LightDM as a login manager seems to have done the trick

Thanks technosaurus, changing from LXDM to LightDM as a login manager seems to have done the trick

@joewing

This comment has been minimized.

Show comment
Hide comment
@joewing

joewing Nov 6, 2014

Owner

Interesting. I think JWM could avoid this issue by doing an XSetInputFocus on the root window as soon as it starts up.

I don't know if the window manager should assume that the root window has input focus at startup and obviously that isn't always the case, so I'm reopening. It should be a trivial fix.

Owner

joewing commented Nov 6, 2014

Interesting. I think JWM could avoid this issue by doing an XSetInputFocus on the root window as soon as it starts up.

I don't know if the window manager should assume that the root window has input focus at startup and obviously that isn't always the case, so I'm reopening. It should be a trivial fix.

@joewing joewing reopened this Nov 6, 2014

@joewing joewing added the bug label Nov 6, 2014

@joewing joewing added this to the Version 2.2.3 milestone Nov 6, 2014

@bbidulock

This comment has been minimized.

Show comment
Hide comment
@bbidulock

bbidulock Nov 7, 2014

Contributor

I don't think you should do that unconditionally: the window manager is not the first client to connect to the X server (it is the dm or xinit). The dm or init process is fully within its rights to maintain focus (e.g. on a splash screen or Xsession selection dialog) while the window manager is launching and even after it has launched. ICCCM rules are that no window should take focus unless it is offered focus by the window manager (e.g. under a sloppy focus model) or the user has clicked in the window. In no event should the window manager be blindly stealing focus. I don't know of any other window manager that does this on startup so it seems to be LXDM's issue. It is possible that it reverts focus to None after startup instead of reverting to Root. If that is the case it might be better to check whether focus is set to None and only then set it to Root. Otherwise stealing focus might break other DMs.

Contributor

bbidulock commented Nov 7, 2014

I don't think you should do that unconditionally: the window manager is not the first client to connect to the X server (it is the dm or xinit). The dm or init process is fully within its rights to maintain focus (e.g. on a splash screen or Xsession selection dialog) while the window manager is launching and even after it has launched. ICCCM rules are that no window should take focus unless it is offered focus by the window manager (e.g. under a sloppy focus model) or the user has clicked in the window. In no event should the window manager be blindly stealing focus. I don't know of any other window manager that does this on startup so it seems to be LXDM's issue. It is possible that it reverts focus to None after startup instead of reverting to Root. If that is the case it might be better to check whether focus is set to None and only then set it to Root. Otherwise stealing focus might break other DMs.

@joewing

This comment has been minimized.

Show comment
Hide comment
@joewing

joewing Nov 7, 2014

Owner

I really don't see why the window manager shouldn't do this, though I agree that the window manager probably shouldn't have to do this. On the other hand, I don't recall seeing it documented anywhere that the input focus is at all specified at startup, so I almost think this is the right thing to do (the input focus could very well be set to None). As far as existing windows are concerned, once the window manager starts the window manager controls the focus, so I would think it could do whatever it wanted. If the DM has a splash screen, the window manager will come to own that window and the DM will need to deal with whatever the window manager decides to do. So if stealing the focus breaks a DM, I would think the DM is broken, or am I missing something? Surely key bindings work with other window managers with LXDM, so maybe there's something else going on here.

Of course, a slightly less heavy-handed method would be to XGetInputFocus and only XSetInputFocus if the input focus window is None.

Owner

joewing commented Nov 7, 2014

I really don't see why the window manager shouldn't do this, though I agree that the window manager probably shouldn't have to do this. On the other hand, I don't recall seeing it documented anywhere that the input focus is at all specified at startup, so I almost think this is the right thing to do (the input focus could very well be set to None). As far as existing windows are concerned, once the window manager starts the window manager controls the focus, so I would think it could do whatever it wanted. If the DM has a splash screen, the window manager will come to own that window and the DM will need to deal with whatever the window manager decides to do. So if stealing the focus breaks a DM, I would think the DM is broken, or am I missing something? Surely key bindings work with other window managers with LXDM, so maybe there's something else going on here.

Of course, a slightly less heavy-handed method would be to XGetInputFocus and only XSetInputFocus if the input focus window is None.

@bbidulock

This comment has been minimized.

Show comment
Hide comment
@bbidulock

bbidulock Nov 7, 2014

Contributor

Yes, XGetInputFocus is what I was suggesting. Consider that if a DM splash dialog (or a popup menu is still posted on the XSession selection), the WM should really not be taking its focus away. Not all windows are necessarily owned by the window manager on startup.

Contributor

bbidulock commented Nov 7, 2014

Yes, XGetInputFocus is what I was suggesting. Consider that if a DM splash dialog (or a popup menu is still posted on the XSession selection), the WM should really not be taking its focus away. Not all windows are necessarily owned by the window manager on startup.

@joewing

This comment has been minimized.

Show comment
Hide comment
@joewing

joewing Jan 2, 2015

Owner

I think this should be fixed now, so I'm closing this. Feel free to reopen if there's still a problem.

Owner

joewing commented Jan 2, 2015

I think this should be fixed now, so I'm closing this. Feel free to reopen if there's still a problem.

@joewing joewing closed this Jan 2, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment