#27976 closed defect (fixed)
Awesome window manager decodes key presses incorrectly.
Reported by: | sipefree@… | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.9.2 |
Keywords: | haspatch | Cc: | cubranic@… |
Port: | awesome |
Description
I've experienced this bug on numerous computers now, all running Snow Leopard and with no difference when using other system keyboard layouts.
It manifests itself by an incorrect decoding of key presses from the user.
I have not mapped out every individual key, but here are some examples:
Pressing Mod-Shift-C to close a window, it is seen as Mod-Shift-7, which moves the window to desktop 7 instead.
Interestingly, Mod-X is supposed to bring up a prompt for executing lua code, which it does, but it also captures Mod-X as Mod-6, which moves to desktop 6.
The number keys are not seen at all, and instead the event is passed to the active window.
I'm not entirely sure if this is a bug in XQuartz, or in Awesome. I suspect this may have something to do with the way Awesome handles events from XCB, since other WMs that use vanilla xlib don't exhibit this problem.
This problem makes the port unusable. Feel free to close it if you believe it's something that should be fixed upstream or in XQuartz, but I'd like to open a dialog with the port maintainer on the issue.
Attachments (1)
Change History (10)
comment:1 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)
Owner: | changed from macports-tickets@… to milosh@… |
---|
comment:2 Changed 13 years ago by jmroot (Joshua Root)
Owner: | changed from milosh@… to macports-tickets@… |
---|
comment:3 Changed 13 years ago by jmroot (Joshua Root)
comment:6 Changed 13 years ago by cubranic@…
I figured out the cause of the problem: it's simply that the keycodes expected in the default config file do not match those on the Mac keyboard. Specifically, the Mod+[1..9] keybindings are defined using keycodes "i+9
", while on my Mac (with a mini wireless keyboard) they are totally different, and more importantly, not in order.
The fix is to instead of keycodes use the keysym, i.e., "1
" instead of "#10
", etc. (The drawback is that this will probably also bind the numeric keypad, but I don't have it and so can't test.) I'm attaching the diff against the default config.
Changed 13 years ago by cubranic@…
Attachment: | rc.lua.diff added |
---|
Diff to lua.rc to fix bindings to numeric keys
comment:7 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Keywords: | haspatch added |
---|---|
Owner: | changed from macports-tickets@… to ryandesign@… |
Status: | new → assigned |
comment:8 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I assume the problem remains in 3.5.1 and I have committed an updated version of the patch in r111731.
However someone should please report the problem to the developers of awesome so that they can fix it properly and we don't have to forever maintain this patch in MacPorts.
comment:9 Changed 11 years ago by jwatzman@…
Pretty sure I remember running into this a couple of years ago and just fixed my own fork of rc.lua instead of here, in retrospect should have submitted a patch too (and thank you for that :)). I think this is either a quirk or bug or something of XQuartz -- the code in awesome upstream works fine on Linux and this patch breaks Linux, IIRC. Definitely worth verifying before filing a bug though, this is just my hazy memory from a while ago :)
Does this still happen with 3.4.10?