Closed 0323pin closed 1 year ago
@jzbor Found it :) Reverting 38a1e7d2891ca77b8aad7d06768b75d3f5b80b8e on git-HEAD fixes the issue. I've applied the following patches on top of 7c750e4b2a6cbc1b69668afb20320666421c0636 to revert the changes implemented in 38a1e7d2891ca77b8aad7d06768b75d3f5b80b8e and my keys are working again.
--- libmars/src/common/x11/mod.rs.orig 2023-07-21 17:12:09.000000000 +0000
+++ libmars/src/common/x11/mod.rs
@@ -79,17 +79,6 @@ impl From<*mut xlib::Screen> for Monitor
}
}
-
-/// Returs all permutiations of your modifiers with NumLock and Level3
-pub fn alternative_modifiers(modifiers: u32) -> Vec<u32> {
- vec![
- modifiers,
- modifiers | xlib::Mod2Mask,
- modifiers | xlib::Mod5Mask,
- modifiers | xlib::Mod2Mask, xlib::Mod5Mask,
- ]
-}
-
/// Waits for MapNotify on the specified window.
/// Discards all events before the MapNotify.
pub fn await_map_notify(display: *mut xlib::Display, window: xlib::Window) {
@@ -258,7 +247,8 @@ pub fn query_monitor_config(display: *mu
/// Remove unrelated mask bits on button or key events
pub fn sanitize_modifiers(modifiers: u32) -> u32 {
- modifiers & (xlib::ShiftMask | xlib::ControlMask | xlib::Mod1Mask | xlib::Mod3Mask | xlib::Mod4Mask)
+ modifiers & (xlib::ShiftMask | xlib::ControlMask | xlib::Mod1Mask | xlib::Mod2Mask
+ | xlib::Mod3Mask | xlib::Mod4Mask |xlib::Mod5Mask)
}
/// Send a ClientMessage to the default root window
and
--- libmars/src/wm/x11/client.rs.orig 2023-07-21 17:12:09.000000000 +0000
+++ libmars/src/wm/x11/client.rs
@@ -287,22 +287,17 @@ impl<A: PartialEq> Client<A> for X11Clie
ButtonTarget::Frame => return, // already grabbed as we own the window
ButtonTarget::Root => panic!("You can't bind actions to the root window through a client window"),
};
-
- for modifiers in alternative_modifiers(modifiers) {
- unsafe {
- xlib::XGrabButton(self.display, button, modifiers, window, xlib::False, mask,
- xlib::GrabModeAsync, xlib::GrabModeAsync, window, 0);
- }
+ unsafe {
+ xlib::XGrabButton(self.display, button, modifiers, window, xlib::False, mask,
+ xlib::GrabModeAsync, xlib::GrabModeAsync, window, 0);
}
}
fn bind_key(&mut self, modifiers: u32, key: u32) {
unsafe {
let keycode = xlib::XKeysymToKeycode(self.display, key.into());
- for modifiers in alternative_modifiers(modifiers) {
- xlib::XGrabKey(self.display, keycode.into(), modifiers, self.frame, xlib::False,
- xlib::GrabModeAsync, xlib::GrabModeAsync);
- }
+ xlib::XGrabKey(self.display, keycode.into(), modifiers, self.frame, xlib::False,
+ xlib::GrabModeAsync, xlib::GrabModeAsync);
}
}
I think the problem comes from Mod5 being alt gr
, ISO_Level3_Shift according to xev
What to do?
Can this be fixed without reverting the whole thing and messing your numlock fix?
Hi, thanks for reporting. I never noticed this, as although I have a German keyboard I changed around the modifiers a lot, until Win was my Level Shift Key. Does the issue relate to marswm keybindings not working with AltGr or level shift not working in regular applications (i.e. you can't produce a $ character)?
I think the issue is the alternative_modifiers()
function. Maybe it shouldn't include Level3 after all. I am not sure what my intention was including it, but the commit itself aimed at avoiding keybindings not getting triggered when num lock is on. Maybe I confused it with caps lock, not sure.
Does the issue relate to marswm keybindings not working with AltGr or level shift not working in regular applications (i.e. you can't produce a $ character)?
Not sure what you are asking exactly but, yes I can not type $
.
Also, I can not type @
, £
and {
(AltGr 2, 3 and 7). While [
, ]
and }
, i.e. AltGr 8,9 and 0 work fine.
Applying the above patches make all keys work as they should. Btw, I don't have any issues with numlock anyway. No keybindings work when numlock is on even on the build with the patches reverting 38a1e7d2891ca77b8aad7d06768b75d3f5b80b8e
Btw, I don't have any issues with numlock anyway. No keybindings work when numlock is on even on the build with the patches reverting https://github.com/jzbor/marswm/commit/38a1e7d2891ca77b8aad7d06768b75d3f5b80b8e
Yes this was the issue I had. I wanted keybindings to work, regardless of whether NumLock was active or not.
Can you try applying this patch on master
?
diff --git a/libmars/src/common/x11/mod.rs b/libmars/src/common/x11/mod.rs
index b1e07f3..02946ae 100644
--- a/libmars/src/common/x11/mod.rs
+++ b/libmars/src/common/x11/mod.rs
@@ -85,8 +85,6 @@ pub fn alternative_modifiers(modifiers: u32) -> Vec<u32> {
vec![
modifiers,
modifiers | xlib::Mod2Mask,
- modifiers | xlib::Mod5Mask,
- modifiers | xlib::Mod2Mask, xlib::Mod5Mask,
]
}
Can you try applying this patch on master?
Yes, of course. As expected, the issue was as I suspected coming from
I think the problem comes from Mod5 being alt gr, ISO_Level3_Shift according to xev
Your patch above is enough to fix all my keys without the need to revert the whole 38a1e7d2891ca77b8aad7d06768b75d3f5b80b8e
Also ...
Yes this was the issue I had. I wanted keybindings to work, regardless of whether NumLock was active or not.
Keybindings work now, even when NumLock is on.
0.5.1 release?
It's fixed with your patch above.
Ok. I will apply the patch to master
and prepare a new release, when I am home...
Hi,
I've been experiencing some issues with my keyboard and was planning a re-install tomorrow. Fortunately, I've decide to test it a bit further before a full OS re-install.
I have a Swedish keyboard on my laptop, https://www.branah.com/swedish, where
Alt gr
+2 should yield@
,Alt gr
+4 should yield$
and so on.Lately only keys 8, 9 and 0 were working with
Alt gr
, yielding[
,]
and}
respectively. Keys 2, 3, 4 and 7 were apparently broken when usingAlt gr
and I could not type@
,£
,$
and{
respectively.Today, I've installed
frankenwm
andleftwm
releases and those keys are working fine. I've been runningmarswm
built from git-HEAD since April, so I've tested releases 0.5.0 and 0.4.1With 0.5.0, I have the same issue as with a git-HEAD build from 7c750e4b2a6cbc1b69668afb20320666421c0636 but, with 0.4.1 release everything is working.
I've looked through, https://github.com/jzbor/marswm/compare/0.4.1...0.5.0 but, I don't know which commit introduced the bug, yet.
For now, I'm running 0.4.1 release but, I'd like to get back to git-HEAD. Thanks!