awesome

Welcome to awesome bug tracking system.
Tasklist

FS#761 - meta+r run diag. reads spacebar as numbers instead of/with space

Attached to Project: awesome
Opened by brendan (kifo) - Wednesday, 05 May 2010, 05:37 GMT
Task Type Bug Report
Category Core
Status Unconfirmed
Assigned To No-one
Operating System Linux
Severity Very Low
Priority Normal
Reported Version git/master
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Awesome:
Build: Sep 23 2009 16:22:19 for i686 by gcc version 4.4.1 (buildd@palmer)
D-Bus support: ?

Ubuntu:
9.10 Karmic
Kernel: 2.6.31-20-generic

By run diag., I mean the run and run lua dialogs in the bar. This ONLY happens in awesome and ONLY in those two dialogs.

In the run dialogs, the spacebar acts strangely if the entire bar is not depressed. This happens on my broken spacebar (one spring busted), on split-space keyboards (at least the one I tried), and can be reproduced easily by removing the spacebar. Most seem to have 4 'sockets' (a few of mine have 3, the inner two seem to be interchangable), and if not all four are pressed, the run dialog treats it differently than a space.

On the keyboards I've tried, this is what happens. The left socket produces a "4", the right socket produces a "1", and the center (single or both, doesn't matter) makes a " ". Those combined together will produce their respective characters without cancelling out, i.e. the left and center socket produces either " 4" or "4 ". Again, this ONLY happens in the run dialogs.

Forgive me for not remembering the command, but a while ago I had pulled up the values registered for these presses, and all three WERE different, however everything else seems to simply ignore the numbers, regardless of which socket is pressed, and ALWAYS registers a space. This creates problems for users with a split spacebar also.
This task depends upon

Comment by Uli Schlachter (psychon) - Friday, 07 May 2010, 09:18 GMT
Awesome only uses what the X server tells it was pressed. The X server gets its info from the kernel which gets its info from the hardware. No idea how, but this really sounds like a hardware problem.

Could you check via xev what the X server thinks was pressed? (Run xev, press keys in its window and watch xev's console output)
Comment by brendan (kifo) - Thursday, 01 July 2010, 02:10 GMT
Left Space Press:


KeyPress event, serial 28, synthetic NO, window 0x2c00001,
root 0xec, subw 0xa007c3, time 73787247, (19,996), root:(20,1016),
state 0x10, keycode 131 (keysym 0xff34, Hangul_Hanja), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2c00001,
root 0xec, subw 0xa007c3, time 73787455, (19,996), root:(20,1016),
state 0x10, keycode 131 (keysym 0xff34, Hangul_Hanja), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False



Right Space Press:


KeyPress event, serial 28, synthetic NO, window 0x2c00001,
root 0xec, subw 0xa007c3, time 73788768, (19,996), root:(20,1016),
state 0x10, keycode 130 (keysym 0xff31, Hangul), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2c00001,
root 0xec, subw 0xa007c3, time 73788976, (19,996), root:(20,1016),
state 0x10, keycode 130 (keysym 0xff31, Hangul), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False



Center Space Press (sorry, backwards):


KeyRelease event, serial 28, synthetic NO, window 0x2c00001,
root 0xec, subw 0x0, time 74141585, (639,748), root:(640,768),
state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
XLookupString gives 1 bytes: (20) " "
XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x2c00001,
root 0xec, subw 0x0, time 74142121, (639,748), root:(640,768),
state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
XLookupString gives 1 bytes: (20) " "
XmbLookupString gives 1 bytes: (20) " "
XFilterEvent returns: False



If those key codes, the left and right space, are generated by the spacebar, maybe they could be read as simply space by awesome? Most other applications seem to behave this way.
Comment by Uli Schlachter (psychon) - Thursday, 01 July 2010, 15:23 GMT
Google only found the following bug report on ubuntu: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/304799

Hm... Looking at the source code, I don't know how it could turn keycode 131/130 into some actually letters (also, what's Hangul_Hanja and Hangul anyway?)
Comment by brendan (kifo) - Monday, 05 July 2010, 00:54 GMT
I wish there were another way for someone to try reproducing this other than prying off their spacebar, if anyone has a split spacebar, maybe they can try to confirm with xev and/or the run diag.

Loading...