[HHKB] Calling on all/any *nix users.

[tuxsavvy]

Hi,

For quite a while I have been fighting with the likes of xmodmap along with my Desktop Environment (DE) on my HHKB JP. After deciding the best idea was to more or less write a complete xmodmap from ground up I faced issues from left, right and centre.

First was the dedicated navigation keys that did not work properly. The Up arrow does not actually show me the previous command that I wrote in yakuake. The left arrow in browser (firefox) which was very annoying, it would go back a page instead of allowing me to navigate around texts when writing/responding to forum posts. Even worse was when using left arrow key and holding the key down it does not repeat the same command. In other words if I were to navigate backwards for text I had to keep tapping the left arrow key to get the desire affect.

Second, after trying to deliberately remap right shift key to as Up arrow key, that worked but I still lost functionality of the left arrow key. I noticed yakuake shortcut did not work. For opening/closing the yakuake session the default key binding was F12. On my HHKB JP it corresponds to Fn+^. No matter how many times I have tried rebinding F12 to yakuake (it even detects the key presses as F12) it would not work instead it prints "4~" within the console window. Rebinding to other keys does not work.

Then gradually as I dug deeper I found out that my DE, specifically KDE4 shortcuts does not work. I cannot start Krunner (normally via Alt+F2 which is equivalent to HHKB JP's Alt+Fn+2), I cannot Alt+Tab to switch between windows. There are other shortcuts that for the life of me I cannot get it to work.

No matter how many times I have tried customising my xmodmap the issue still remained there. I have consulted several times with HaaTa considering I based my xmodmap config file off HaaTa's yet the issue lies with my KDE4 or so I still believe now. It was only just two days ago that I after having my old keyboard (APC Clicker F-21) plugged in I noticed some interesting discoveries. The shortcuts work fine under KDE and there were probably no issues with navigating using arrow keys.

I then started checking my xmodmap -pm configuration and amazingly because my HHKB JP (this also applies to HHKB as well mind you) that there were no Num_Lock, Scroll_Lock keys. Yet when I "artificially" bound a non-existant key (on my HHKB JP) for Num_Lock and then eventually Scroll_Lock along with adding entries to modifiers my HHKB JP works fine now with KDE4. It seems like all the issues that I had earlier seems irrelevant.

This now leaves me some questions:

• Does KDE4 require Num_Lock and Scroll_Lock defined? on HHKB these keys obviously do not exist but it seems to me that KDE4 will not want to co-operate without it.
• Is this issue only specific to KDE4? has anyone else tried say for example Gnome and seen the same sort of thing happening?
• Could there be chances that X11 for instance at startup (after logging in), it assumes that any keyboard plugged in after the initial "detecting phase" should have the same keys? For example if I had a full sized keyboard detected since booting, could X11 have since assumed that any subsequent keyboard I plug in will be full sized even though it is not (as HHKB is only 60%)?

Here is my .Xmodmap_HHKB_JP which is made to work with HHKB JP. Initially it was written based off windows mode (via DIP switches but I realised under mac mode there are no losses except it adds extra keycodes for mainly multimedia stuff):

Code: [Select]

psycho_oreo's (tuxsavvy) somewhat exhaustive XModMap for Japanese Happy Hacking Professional v0.02b
!
! Purpose:
! To create a tailor made .Xmodmap suited to Japanese Happy Hacking Professional series under *nix environment.
!
! The bulk of this design borrows HaaTa's idea along with a few things shamelessly copied from HaaTa's work. You can see HaaTa's work at: https://www.dropbox.com/sh/053g7cprxpq4uxb/MADgbg4QLP.
! Ideas were based from HaaTa's Japanese Topre RealForce with Windows key - Shai Coleman's Co except with the intention to create the layout as it is printed on the keyboard. In other words,
! this is not a Colemak layout but a Qwerty layout. Whatever key you see on the Japanese HHKB pressing it will give you the literal output of what it was meant to be.
!
! keycodes are numbered in numerical order to prevent confusion along with able to see missing keycodes. If the layout may be deemed to be messy compared to what one would ideally like the layout
! to be you are welcome to change the layout to match your taste.
!
! Notes:
! - No keycode for "Volume Down" key under windows mode but under mac mode it produces a keycode.
!# keycode  122 = XF86AudioLowerVolume NoSymbol XF86AudioLowerVolume
! - No keycode for "Volume Up" key under windows mode but under mac mode it produces a keycode.
!# keycode  123 = XF86AudioRaiseVolume NoSymbol XF86AudioRaiseVolume
! - No keycode for "Mute" key under windows mode but under mac mode it produces a keycode.
!# keycode  121 = XF86AudioMute NoSymbol XF86AudioMute
! - No keycode for "Eject" key under windows mode but under mac mode it produces a keycode.
!# keycode  198 = XF86Eject XF86Eject XF86Eject XF86Eject
! - Fn+{@,`} gives the same keycode (111) as the dedicated "Up" arrow key. Therefore it is not needed for keybinding.
! - Fn+{;,+} gives the same keycode (117) as the dedicated "Left" arrow key. Therefore it is not needed for keybinding.
! - Fn+{:,*} gives the same keycode (114) as the dedicated "Right" arrow key. Therefore it is not needed for keybinding.
! - Fn+{/,?} gives the same keycode (116) as the dedicated "Down" arrow key. Therefore it is not needed for keybinding.
! - Fn+Up key gives the same keycode as Shift_R hence there is no need to make a dedicated line for it. Besides there would now be two SHift_R keys for JP variant of HHKB.
! - "Opt" key is the Macintosh's equivalent of "Alt" key. It means Option, they function the same.
! - No keycode for the "Power" key found on the "Esc" key under windows mode but under mac mode it produces a keycode.
!# keycode  124 = XF86PowerOff XF86PowerOff XF86PowerOff XF86PowerOff
! - Apart from "xev", "xinput test <device number>" can also be used to audit for keycodes. The output is not as verbose as xev but it does not also produce a test window for mouse
!   pointer tests as well as the need for xev's own window to be active in order to print and capture keycodes.
!
! Changelog:
! 0.02b - Corrected a previous statement on Scroll_Lock requiring artifical implementation. HHKB does have Scroll_Lock via Fn layer.
!       - Added XF86Switch keys which is a necessity for those who wants to switch between vty and X daemon(s).
! 0.02a - Fixed up some issues with some of the KDE4 quirks. It appears at times mod1 is bound to Alt_L and Left for some reason which
!         makes the Left key repeating once when pressed and held down.
!       - Fixed up an issue where coincidentally the same issue would cause browsers such as firefox to go back when Left button is accidentally pressed. This goes in conjunction with
!         former issue.
!       - Added Num_Lock artificially as KDE4 for instance would fail to have the shortcuts working properly. HHKB does not have Num_Lock. keycode 77.
!       - Bound the artificial Num_Lock as a modifier key to mod/groups. Num_Lock goes into mod2.
!       - Added extra keycodes when HHKB is set to Mac mode. All the multimedia, etc keys now have corresponding keycodes. You may want to comment them out later on if you do not want
!         such functionalities.
!       - Rebinded Shift_R key as sometimes the Up key does not work as expected.
! 0.01b - Using xev to obtain keycodes instead of scankey which gave completely the wrong keycodes.
!       - Added extra keys for Fn+<key> variants
!       - All the non-alphanumerical keys such as symbols and modifiers have been replaced with the appropriate names as listed in keysymdef.h as well as XF86keysym.h.
!       - Borrowed HaaTa's work on clearing modifiers, unbinding any unused keys, as well as definitions found on the "header" of his .Xmodmap.
!       - Used HaaTa's layout with keycodes being numerically ordered. It is far more legible than the old idea of going from right to left like reading English texts.
!       - In addition to what was written above for being numerically ordered. Any unused keycodes has been labelled to "NOT_SPECIFIED".
! 0.01a - Not for public release.
!       - Initial "skeletal" layout heavily using "scankey -k" command which gave out completely different set of keycodes as opposed to xev.
!       - No "header" details and no Fn+<key> binded.
!       - Unconventional layout with keycodes starting from left to right on the keyboard like as if reading English texts.
!
! Todo:
! - License this layout? :p
! - Maybe add more keycodes based on the varied DIP switch configurations.
!
! Unlike loadkeys, modifiers are completely separate from the actual keysym definitions.
! Shift is a notable exception though.
!
! Example keycode:
!                | Group 1 | Group 2 | Group 3 | Group 5 |
!  keycode  24 =     q W       d D       b B       v V
!
! Note: Don't ask me where Group 4 is, cause it doesn't exist. Why? Dunno, go complain to the xkb guys
!
! Each group has a plain and shifted keysym, by default Group 1 is always selected.
! The following keysyms can switch between the different ISO Groups:
!
!  | Group 2 Keysyms |
! ISO_Level2_Latch
!
!  | Group 3 Keysyms |
! ISO_Level3_Shift
! ISO_Level3_Latch
! ISO_Level3_Lock
!
!  | Group 5 Keysyms |
! ISO_Level5_Shift
! ISO_Level5_Latch
! ISO_Level5_Lock
!
!  | Generic Keysyms |
! ISO_Group_Shift
! ISO_Group_Latch
! ISO_Group_Lock
! ISO_Next_Group
! ISO_Next_Group_Lock
! ISO_Prev_Group
! ISO_Prev_Group_Lock
! ISO_First_Group
! ISO_First_Group_Lock
! ISO_Last_Group
! ISO_Last_Group_Lock
!
! XModMap allows for up to 8 modifiers to be specified, the first 4 which are in standard use:
! shift   - Shift    Modifier (Common use)
! lock    - CapsLock Modifier (Common use)
! control - Ctrl     Modifier (Common use)
! mod1    - Alt/Meta Modifier (Common use)
! mod2    - NOT_SPECIFIED
! mod3    - NOT_SPECIFIED
! mod4    - Super    Modifier (Common use with the Windows/Logo key)
! mod5    - NOT_SPECIFIED     (Often AltGr though)
!
!
! Clean-up all of the modifiers
clear Shift
clear Lock
clear Control
clear Mod1
clear Mod2
clear Mod3
clear Mod4
clear Mod5
!
! XModMap keycodes starts at 8 and goes up to 255.
! Even though the syntax is quite similar to loadkeys, functionally XModMap is completely different...
!
! A reletively full list of keysyms can be found in: include/X11/keysymdef.h as well as include/X11/XF86keysymdef.h
! Custom keysyms can be added, documentation exists for this however.
!# Keycode 8 - NOT_SPECIFIED
keycode  8 =

!# Keycode  9 - Esc
keycode  9 = Escape NoSymbol Escape

!# Keycode  10 - 1 !
keycode  10 = 1 exclam 1 exclam

!# Keycode  11 - 2 "
keycode  11 = 2 quotedbl 2 quotedbl

!# Keycode  12 - 3 #
keycode  12 = 3 numbersign 3 numbersign

!# Keycode  13 - 4 $
keycode  13 = 4 dollar 4 dollar

!# Keycode  14 - 5 %
keycode  14 = 5 percent 5 percent

!# Keycode  15 - 6 &
keycode  15 = 6 ampersand 6 ampersand

!# Keycode  16 - 7 '
keycode  16 = 7 apostrophe 7 apostrophe

!# Keycode  17 - 8 (
keycode  17 = 8 parenleft 8 parenleft

!# Keycode  18 - 9 )
keycode  18 = 9 parenright 9 parenright

!# Keycode  19 - 0 ヲ (That was not expected, there's nothing else printed on the same key apart from 0 and F10.)
keycode  19 = 0 kana_WO 0 kana_WO

!# Keycode  20 - - =
keycode  20 = minus equal minus equal

!# Keycode  21 - ^ ~
keycode  21 = asciicircum asciitilde asciicircum asciitilde

!# Keycode  22 - BackSpace
keycode  22 = BackSpace NoSymbol BackSpace

!# Keycode  23 - Tab
keycode  23 = Tab ISO_Left_Tab Tab ISO_Left_Tab

keycode  24 = q Q

keycode  25 = w W

keycode  26 = e E

keycode  27 = r R

keycode  28 = t T

keycode  29 = y Y

keycode  30 = u U

keycode  31 = i I

keycode  32 = o O

keycode  33 = p P

!# Keycode  34 - @ `
keycode  34 = at grave at grave 

!# Keycode  35 - [ {
keycode  35 = bracketleft braceleft bracketleft braceleft

keycode  36 = Return NoSymbol Return

!# Keycode  37 - Control_L
keycode  37 = Control_L Control_L Control_L Control_L

keycode  38 = a A

keycode  39 = s S

keycode  40 = d D

keycode  41 = f F

keycode  42 = g G

keycode  43 = h H

keycode  44 = j J

keycode  45 = k K

keycode  46 = l L

!# Keycode  47 - ; +
keycode  47 = semicolon plus semicolon plus

!# Keycode  48 - : *
keycode  48 = colon asterisk colon asterisk

!# Keycode  49 - Zenkaku_Hankaku
keycode  49 = Zenkaku_Hankaku NoSymbol Zenkaku_Hankaku

!# Keycode  50 - Shift_L
keycode  50 = Shift_L Shift_L Shift_L Shift_L

!# Keycode  51 - ] }
keycode  51 = bracketright braceright bracketright braceright

keycode  52 = z Z

keycode  53 = x X

keycode  54 = c C

keycode  55 = v V

keycode  56 = b B

keycode  57 = n N

keycode  58 = m M

!# Keycode  59 - , <
keycode  59 = comma less comma less

!# Keycode  60 - . >
keycode  60 = period greater period greater

!# Keycode  61 - / ?
keycode  61 = slash question slash question

!# Keycode  62 - Shift_R
keycode  62 = Shift_R NoSymbol Shift_R

!# Keycode  63 - *
keycode  63 = asterisk asterisk asterisk asterisk

!# Keycode  64 - Alt_L
keycode  64 = Alt_L NoSymbol Alt_L

!# Keycode  65 - space
keycode  65 = space NoSymbol space

!# Keycode  66 - Eisu_toggle (Actually it's printed as "Caps" on the keyboard but whatever)
!keycode  66 = Eisu_toggle NoSymbol Eisu_toggle
!keycode  66 = Eisu_toggle Caps_Lock
keycode  66 = Caps_Lock ISO_Next_Group Eisu_toggle Caps_Lock

keycode  67 = F1 F1 F1 F1 F1 F1 XF86Switch_VT_1

keycode  68 = F2 F2 F2 F2 F2 F2 XF86Switch_VT_2

keycode  69 = F3 F3 F3 F3 F3 F3 XF86Switch_VT_3

keycode  70 = F4 F4 F4 F4 F4 F4 XF86Switch_VT_4

keycode  71 = F5 F5 F5 F5 F5 F5 XF86Switch_VT_5

keycode  72 = F6 F6 F6 F6 F6 F6 XF86Switch_VT_6

keycode  73 = F7 F7 F7 F7 F7 F7 XF86Switch_VT_7

keycode  74 = F8 F8 F8 F8 F8 F8 XF86Switch_VT_8

keycode  75 = F9 F9 F9 F9 F9 F9 XF86Switch_VT_9

keycode  76 = F10 F10 F10 F10 F10 F10 XF86Switch_VT_10

!# Keycode 77 - NOT_SPECIFIED but artificially added for handling DE/WM specific quirks.
keycode  77 = Num_Lock NoSymbol Num_Lock Pointer_EnableKeys

!# Keycode 78 - Scroll_Lock
keycode  78 = Scroll_Lock NoSymbol Scroll_Lock

!# Keycode 79 - NOT_SPECIFIED
keycode  79 =

!# Keycode 80 - NOT_SPECIFIED
keycode  80 =

!# Keycode 81 - NOT_SPECIFIED
keycode  81 =

!# Keycode  82 - -
keycode  82 = minus minus minus minus

!# Keycode 83 - NOT_SPECIFIED
keycode  83 =

!# Keycode 84 - NOT_SPECIFIED
keycode  84 =

!# Keycode 85 - NOT_SPECIFIED
keycode  85 =

!# Keycode  86 - +
keycode  86 = plus plus plus plus

!# Keycode 87 - NOT_SPECIFIED
keycode  87 =

!# Keycode 88 - NOT_SPECIFIED
keycode  88 =

!# Keycode 89 - NOT_SPECIFIED
keycode  89 =

!# Keycode 90 - NOT_SPECIFIED
keycode  90 =

!# Keycode 91 - NOT_SPECIFIED
keycode  91 =

!# Keycode 92 - NOT_SPECIFIED
keycode  92 =

!# Keycode 93 - NOT_SPECIFIED
keycode  93 =

!# Keycode 94 - NOT_SPECIFIED
keycode  94 =

keycode  95 = F11 F11 F11 F11 F11 F11 XF86Switch_VT_11

keycode  96 = F12 F12 F12 F12 F12 F12 XF86Switch_VT_12

!# Keycode  97 - \ _
keycode  97 = backslash underscore backslash underscore

!# Keycode 98 - NOT_SPECIFIED
keycode  98 =

!# Keycode 99 - NOT_SPECIFIED
keycode  99 =

!# Keycode  100 - Henkan_Mode
keycode  100 = Henkan_Mode NoSymbol Henkan_Mode

!# Keycode  101 - Hiragana_Katakana
keycode  101 = Hiragana_Katakana NoSymbol Hiragana_Katakana

!# Keycode  102 - Muhenkan
keycode  102 = Muhenkan NoSymbol Muhenkan

!# Keycode 103 - NOT_SPECIFIED
keycode  103 =

!# Keycode 104 - NOT_SPECIFIED
keycode  104 =

!# Keycode  105 - Control_R
keycode  105 = Control_R NoSymbol Control_R

!# Keycode  106 - /
keycode  106 = slash slash slash slash

!# Keycode  107 - Print (and Sys_Req key, no separate keycode for Sys_Rq itself and it is needed on Linux "Magic SysRq key").
keycode  107 = Print Sys_Req Print Sys_Req

!# Keycode  108 - Alt_R
keycode  108 = Alt_R NoSymbol Alt_R

!# Keycode 109 - NOT_SPECIFIED
keycode  109 =

!# Keycode  110 - Home
keycode  110 = Home Home Home Home

!# Keycode  111 - Up
keycode  111 = Up NoSymbol Up

!# Keycode  112 - Page Up
keycode  112 = Prior Prior Prior Prior

!# Keycode  113 - Left
keycode  113 = Left Left Left Left

!# Keycode  114 - Right
keycode  114 = Right Right Right Right

!# Keycode  115 - End
keycode  115 = End End End End

!# Keycode  116 - Down
keycode  116 = Down Down Down Down

!# Keycode  117 - Page Down
keycode  117 = Next Next Next Next

!# Keycode  118 - Insert
keycode  118 = Insert NoSymbol Insert

!# Keycode  119 - Delete
keycode  119 = Delete NoSymbol Delete

!# Keycode 120 - NOT_SPECIFIED
keycode  120 =

!# Keycode 121 - NOT_SPECIFIED
!keycode  121 =

!# Keycode 121 - NOT_SPECIFIED under windows mode but XF86AudioMute under Mac mode via DIP switch.
keycode  121 = XF86AudioMute NoSymbol XF86AudioMute

!# Keycode 122 - NOT_SPECIFIED
!keycode  122 =

!# Keycode 122 - NOT_SPECIFIED under windows mode but XF86AudioLowerVolume under Mac mode via DIP switch.
keycode  122 = XF86AudioLowerVolume NoSymbol XF86AudioLowerVolume

!# Keycode 123 - NOT_SPECIFIED
!keycode  123 =

!# Keycode 123 - NOT_SPECIFIED under windows mode but XF86AudioRaiseVolume under Mac mode via DIP switch.
keycode  123 = XF86AudioRaiseVolume NoSymbol XF86AudioRaiseVolume

!# Keycode 124 - NOT_SPECIFIED
!keycode  124 =

!# Keycode 124 - NOT_SPECIFIED under windows mode but XF86PowerOff under Mac mode via DIP switch.
keycode  124 = XF86PowerOff XF86PowerOff XF86PowerOff XF86PowerOff

!# Keycode 125 - NOT_SPECIFIED
keycode  125 =

!# Keycode 126 - NOT_SPECIFIED
keycode  126 =

!# Keycode  127 - Pause (and Break key, no separate keycode for Break itself and it would be handy to have).
keycode  127 = Pause Break Pause Break

!# Keycode 128 - NOT_SPECIFIED
keycode  128 =

!# Keycode 129 - NOT_SPECIFIED
keycode  129 =

!# Keycode 130 - NOT_SPECIFIED
keycode  130 =

!# Keycode 131 - NOT_SPECIFIED
keycode  131 =

!# Keycode  132 - ¥ |
keycode  132 = yen bar yen bar

!# Keycode  133 - Super_L
keycode  133 = Super_L NoSymbol Super_L

!# Keycode  134 - Super_R
keycode  134 = Super_R NoSymbol Super_R

!# Keycode 135 - NOT_SPECIFIED
keycode  135 =

!# Keycode 136 - NOT_SPECIFIED
keycode  136 =

!# Keycode 137 - NOT_SPECIFIED
keycode  137 =

!# Keycode 138 - NOT_SPECIFIED
keycode  138 =

!# Keycode 139 - NOT_SPECIFIED
keycode  139 =

!# Keycode 140 - NOT_SPECIFIED
keycode  140 =

!# Keycode 141 - NOT_SPECIFIED
keycode  141 =

!# Keycode 142 - NOT_SPECIFIED
keycode  142 =

!# Keycode 143 - NOT_SPECIFIED
keycode  143 =

!# Keycode 144 - NOT_SPECIFIED
keycode  144 =

!# Keycode 145 - NOT_SPECIFIED
keycode  145 =

!# Keycode 146 - NOT_SPECIFIED
keycode  146 =

!# Keycode 147 - NOT_SPECIFIED
keycode  147 =

!# Keycode 148 - NOT_SPECIFIED
keycode  148 =

!# Keycode 149 - NOT_SPECIFIED
keycode  149 =

!# Keycode 150 - NOT_SPECIFIED
keycode  150 =

!# Keycode 151 - NOT_SPECIFIED
keycode  151 =

!# Keycode 152 - NOT_SPECIFIED
keycode  152 =

!# Keycode 153 - NOT_SPECIFIED
keycode  153 =

!# Keycode 154 - NOT_SPECIFIED
keycode  154 =

!# Keycode 155 - NOT_SPECIFIED
keycode  155 =

!# Keycode 156 - NOT_SPECIFIED
keycode  156 =

!# Keycode 157 - NOT_SPECIFIED
keycode  157 =

!# Keycode 158 - NOT_SPECIFIED
keycode  158 =

!# Keycode 159 - NOT_SPECIFIED
keycode  159 =

!# Keycode 160 - NOT_SPECIFIED
keycode  160 =

!# Keycode 161 - NOT_SPECIFIED
keycode  161 =

!# Keycode 162 - NOT_SPECIFIED
keycode  162 =

!# Keycode 163 - NOT_SPECIFIED
keycode  163 =

!# Keycode 164 - NOT_SPECIFIED
keycode  164 =

!# Keycode 165 - NOT_SPECIFIED
keycode  165 =

!# Keycode 166 - NOT_SPECIFIED
keycode  166 =

!# Keycode 167 - NOT_SPECIFIED
keycode  167 =

!# Keycode 168 - NOT_SPECIFIED
keycode  168 =

!# Keycode 169 - NOT_SPECIFIED
keycode  169 =

!# Keycode 170 - NOT_SPECIFIED
keycode  170 =

!# Keycode 171 - NOT_SPECIFIED
keycode  171 =

!# Keycode 172 - NOT_SPECIFIED
keycode  172 =

!# Keycode 173 - NOT_SPECIFIED
keycode  173 =

!# Keycode 174 - NOT_SPECIFIED
keycode  174 =

!# Keycode 175 - NOT_SPECIFIED
keycode  175 =

!# Keycode 176 - NOT_SPECIFIED
keycode  176 =

!# Keycode 177 - NOT_SPECIFIED
keycode  177 =

!# Keycode 178 - NOT_SPECIFIED
keycode  178 =

!# Keycode 179 - NOT_SPECIFIED
keycode  179 =

!# Keycode 180 - NOT_SPECIFIED
keycode  180 =

!# Keycode 181 - NOT_SPECIFIED
keycode  181 =

!# Keycode 182 - NOT_SPECIFIED
keycode  182 =

!# Keycode 183 - NOT_SPECIFIED
keycode  183 =

!# Keycode 184 - NOT_SPECIFIED
keycode  184 =

!# Keycode 185 - NOT_SPECIFIED
keycode  185 =

!# Keycode 186 - NOT_SPECIFIED
keycode  186 =

!# Keycode 187 - NOT_SPECIFIED
keycode  187 =

!# Keycode 188 - NOT_SPECIFIED
keycode  188 =

!# Keycode 189 - NOT_SPECIFIED
keycode  189 =

!# Keycode 190 - NOT_SPECIFIED
keycode  190 =

!# Keycode 191 - NOT_SPECIFIED
keycode  191 =

!# Keycode 192 - NOT_SPECIFIED
keycode  192 =

!# Keycode 193 - NOT_SPECIFIED
keycode  193 =

!# Keycode 194 - NOT_SPECIFIED
keycode  194 =

!# Keycode 195 - NOT_SPECIFIED
keycode  195 =

!# Keycode 196 - NOT_SPECIFIED
keycode  196 =

!# Keycode 197 - NOT_SPECIFIED
keycode  197 =

!# Keycode 198 - NOT_SPECIFIED
!keycode  198 =

!# Keycode 198 - NOT_SPECIFIED under windows mode but XF86Eject under Mac mode via DIP switches.
keycode  198 = XF86Eject XF86Eject XF86Eject XF86Eject

!# Keycode 199 - NOT_SPECIFIED
keycode  199 =

!# Keycode 200 - NOT_SPECIFIED
keycode  200 =

!# Keycode 201 - NOT_SPECIFIED
keycode  201 =

!# Keycode 202 - NOT_SPECIFIED
keycode  202 =

!# Keycode 203 - NOT_SPECIFIED
keycode  203 =

!# Keycode 204 - NOT_SPECIFIED
keycode  204 =

!# Keycode 205 - NOT_SPECIFIED
keycode  205 =

!# Keycode 206 - NOT_SPECIFIED
keycode  206 =

!# Keycode 207 - NOT_SPECIFIED
keycode  207 =

!# Keycode 208 - NOT_SPECIFIED
keycode  208 =

!# Keycode 209 - NOT_SPECIFIED
keycode  209 =

!# Keycode 210 - NOT_SPECIFIED
keycode  210 =

!# Keycode 211 - NOT_SPECIFIED
keycode  211 =

!# Keycode 212 - NOT_SPECIFIED
keycode  212 =

!# Keycode 213 - NOT_SPECIFIED
keycode  213 =

!# Keycode 214 - NOT_SPECIFIED
keycode  214 =

!# Keycode 215 - NOT_SPECIFIED
keycode  215 =

!# Keycode 216 - NOT_SPECIFIED
keycode  216 =

!# Keycode 217 - NOT_SPECIFIED
keycode  217 =

!# Keycode 218 - NOT_SPECIFIED
keycode  218 =

!# Keycode 219 - NOT_SPECIFIED
keycode  219 =

!# Keycode 220 - NOT_SPECIFIED
keycode  220 =

!# Keycode 221 - NOT_SPECIFIED
keycode  221 =

!# Keycode 222 - NOT_SPECIFIED
keycode  222 =

!# Keycode 223 - NOT_SPECIFIED
keycode  223 =

!# Keycode 224 - NOT_SPECIFIED
keycode  224 =

!# Keycode 225 - NOT_SPECIFIED
keycode  225 =

!# Keycode 226 - NOT_SPECIFIED
keycode  226 =

!# Keycode 227 - NOT_SPECIFIED
keycode  227 =

!# Keycode 228 - NOT_SPECIFIED
keycode  228 =

!# Keycode 229 - NOT_SPECIFIED
keycode  229 =

!# Keycode 230 - NOT_SPECIFIED
keycode  230 =

!# Keycode 231 - NOT_SPECIFIED
keycode  231 =

!# Keycode 232 - NOT_SPECIFIED
keycode  232 =

!# Keycode 233 - NOT_SPECIFIED
keycode  233 =

!# Keycode 234 - NOT_SPECIFIED
keycode  234 =

!# Keycode 235 - NOT_SPECIFIED
keycode  235 =

!# Keycode 236 - NOT_SPECIFIED
keycode  236 =

!# Keycode 237 - NOT_SPECIFIED
keycode  237 =

!# Keycode 238 - NOT_SPECIFIED
keycode  238 =

!# Keycode 239 - NOT_SPECIFIED
keycode  239 =

!# Keycode 240 - NOT_SPECIFIED
keycode  240 =

!# Keycode 241 - NOT_SPECIFIED
keycode  241 =

!# Keycode 242 - NOT_SPECIFIED
keycode  242 =

!# Keycode 243 - NOT_SPECIFIED
keycode  243 =

!# Keycode 244 - NOT_SPECIFIED
keycode  244 =

!# Keycode 245 - NOT_SPECIFIED
keycode  245 =

!# Keycode 246 - NOT_SPECIFIED
keycode  246 =

!# Keycode 247 - NOT_SPECIFIED
keycode  247 =

!# Keycode 248 - NOT_SPECIFIED
keycode  248 =

!# Keycode 249 - NOT_SPECIFIED
keycode  249 =

!# Keycode 250 - NOT_SPECIFIED
keycode  250 =

!# Keycode 251 - NOT_SPECIFIED
keycode  251 =

!# Keycode 252 - NOT_SPECIFIED
keycode  252 =

!# Keycode 253 - NOT_SPECIFIED
keycode  253 =

!# Keycode 254 - NOT_SPECIFIED
keycode  254 =

!# Keycode 255 - NOT_SPECIFIED
keycode  255 =

add shift   = Shift_L Shift_R
add lock    = Caps_Lock
add control = Control_L Control_R
add mod1    = Alt_L Alt_R
!# add mod2  - Specifically to handle DE/WM quirks.
add mod2    = Num_Lock
!add mod4    = Super_L Super_R Super_L Hyper_L
!# add mod5  - Specifically to handle DE/WM quirks.
add mod5    = Scroll_Lock

I appreciate any sort of input for this weird issue.

[Ansich]

The Arch wiki discourages the use of xmodmap for any major modifications and recommends editing layouts with XKB. Don't get me wrong, I also used xmodmap to do some localization adjustments on my own Linux rig  (I use XFCE) and it works fine for me (I run a bash script at startup that remaps the keycodes that I want to modify), but I do use a keyboard that has the F1-F12 buttons so there might be something else at play here. Perhaps if you are making more significant changes to the layout, editing xkb might be more appropriate?

https://wiki.archlinux.org/index.php/Xmodmap

https://wiki.archlinux.org/index.php/X_KeyBoard_extension

[osi]

Ansich, welcome to geekhack. 

Interesting problem here, will watch this thread.

[Ansich]

p.s.: if the xev utility registers the key presses as they should be, then it is very likely, that the problem lies in the way the DE handles keyboard layouts. I am not familiar with KDE, but it is possible that it just overrides the xmodmap settings by default (check this bug; i glacned over it and it might be a similar problem to what you're dealing with). In that case you would have to make modifications to whatever utility KDE is using to set it's layout.
Here's a lot of info about KDE that might contain some clues.

osi: thanks for the welcome

[kyb]

Hmm, with a HHKB using anything other than a tiling WM (Awesome, Xmonad, etc) is a waste.

[Betty]

I use xmodmap a lot with Awesome and never had such problems, like Ansich I use a Bash script to remap everything at start up/change of keyboard.
Yesterday the Matias Quiet Pro arrived and I had to remap all function keys to their regular purpose because it was detected as an Apple keyboard, which was annoying at first but basically no problem.
Concerning xmodmap I found this article http://who-t.blogspot.de/2010/06/keyboard-configuration-its-complicated.html pretty helpful to get the big picture, it might help and it gives me the intuition that your problem might come from KDE.

[hasu]

Hmm, with a HHKB using anything other than a tiling WM (Awesome, Xmonad, etc) is a waste.

I believe wizard can live without X. We should feel ashamed to fiddle with crappy mouse.

I also use xmodmap sometime but it doesn't work on console. I prefer loadkeys for simple remap.

[tuxsavvy]

The Arch wiki discourages the use of xmodmap for any major modifications and recommends editing layouts with XKB. Don't get me wrong, I also used xmodmap to do some localization adjustments on my own Linux rig  (I use XFCE) and it works fine for me (I run a bash script at startup that remaps the keycodes that I want to modify), but I do use a keyboard that has the F1-F12 buttons so there might be something else at play here. Perhaps if you are making more significant changes to the layout, editing xkb might be more appropriate?

https://wiki.archlinux.org/index.php/Xmodmap

https://wiki.archlinux.org/index.php/X_KeyBoard_extension

Hi, welcome to forum and thanks for your replies!

I was introduced to xmodmap by HaaTa (lol) and the syntaxes for xmodmap seems to be simpler than dealing with xkb after looking at the link you posted (X KeyBoard extension - Archwiki) though in either case it looks like I'll need to almost more or less learn and rebase my work on xkb instead.

You aren't the only person who referred me to xkb, however by reminding me of xkb it looks like I'll yet again need to re-learn the new(er) way again.

Xmodmap on Archwiki, I believe I have read that a few times in the process of attempting to sort out either xmodmap's issues or KDE shortcut woes. Having also many many tabs opened on my browser from various websites discussing about xmodmap there wasn't one simple answer apart from the fact that they all tell me the issue seems to be KDE/X11 specific. The lack of documentation on KDE4 when it comes to dealing with global shortcuts is astounding. I have to ask and poke around the right people to get a somewhat trivial answer.

Ansich, welcome to geekhack. 

Interesting problem here, will watch this thread.

Nothing to see here! Problem seems to be related to KDE4 and was wondering if I am alone on this case or not. 

Considering this reply (from me) is the shortest one out of all the replies that I have given to others and considering how you seem to have interest in this issue I'll post my sources. A forewarning to you or anyone else reading that not all of these links not exactly in English as I have tried broadening my horizons with my efforts on the said issue:

• HHKB Pro2 autoconfigured in Linux distribution
• HHKB Pro Japanese Layout
• keyboard - show keys pressed in linux - Super User
• HaaTa's Dropbox - Public
• XMODMAP
• Some hints about xmodmap(1) and the X11 keyboard model
• Using xmodmap
• Mozc - ArchWiki
• 窓使いの憂鬱使いの憂鬱 - willowletの日記
• Xmodmap でお好みのキーバインド - bearmini's blog
• xmodmap - Esc と ~ を入れ替えてノート PC 本体のキーボードとタッチパッドはオフにする (HHKB Pro2 用設定) - Qiita

For the record, my Japanese is not great, I can only understand portions. )

p.s.: if the xev utility registers the key presses as they should be, then it is very likely, that the problem lies in the way the DE handles keyboard layouts. I am not familiar with KDE, but it is possible that it just overrides the xmodmap settings by default (check this bug; i glacned over it and it might be a similar problem to what you're dealing with). In that case you would have to make modifications to whatever utility KDE is using to set it's layout.
Here's a lot of info about KDE that might contain some clues.

osi: thanks for the welcome

Yeah I was also pointed out by HaaTa that the issue is to do with DE specific quirks. Again the lack of information on trying to "reset" KDE4 global shortcuts was one of my main gripes. HaaTa on the other hand does not run KDE so I cannot really poke him around for issues surrounding a DE that it appears I am the only one that is suffering.

The bug link is interesting, thanks but there was no direct information on how to reset or reload KDE4 global shortcuts which is a little irritating considering now that I had to fake up two keys to make my case work with KDE4 config.

I have had a whole bunch of tabs on my web browser opened on KDE's shortcut issues (even bug reports) but there were no direct pointers to fix up the global shortcuts configuration. Since resolving the issue alone on my end I no longer kept tabs on the KDE issue but instead focus on what an hackish attempt to get my HHKB to work (ironic even for its name).

Hmm, with a HHKB using anything other than a tiling WM (Awesome, Xmonad, etc) is a waste.

Personal preferences, personal preferences.  I have tried a fair few other different WM/DE before tiling WM became a little more friendly and now I feel like an old man that doesn't really care about wasting system resources on using something as big and ineffective as KDE.

Have had already played with KDE, Gnome, TWM, XFCE, LXDE, Fluxbox as well as enlightment plus I have tried some other lesser known WM just for curious sakes.

Someday I might again jump the ship and go into tiling WM but for now I must choose some more eye-candy DE so that I can convert some windows users. Not scare them away by having tiling WM or having just the black and white console screen. Besides I am fairly formidable with console, I can't really live without it. Regardless of which WM/DE I am on I always have at least one console session running somewhere within the X environment plus I switch between virtual terminals back and forth.

I use xmodmap a lot with Awesome and never had such problems, like Ansich I use a Bash script to remap everything at start up/change of keyboard.
Yesterday the Matias Quiet Pro arrived and I had to remap all function keys to their regular purpose because it was detected as an Apple keyboard, which was annoying at first but basically no problem.
Concerning xmodmap I found this article http://who-t.blogspot.de/2010/06/keyboard-configuration-its-complicated.html pretty helpful to get the big picture, it might help and it gives me the intuition that your problem might come from KDE.

Thanks for response. The more I hear of it it does sound like it is DE (particularly KDE4) specific. Ugh! really irritating that I had to resort some hackish attempt. Maybe xkb may solve my issues.

My issues started as soon as I switched from full sized keyboard to 60% so I can sort of relate to the pain you have.

The link on xmodmap is interesting, it partially answers why HaaTa has so many xmodmap config for each individual keyboard. xkb maybe is the successor to xmodmap but xmodmap's "language" seems more friendly to figure out. xkb just seems a little more alien.

Hmm, with a HHKB using anything other than a tiling WM (Awesome, Xmonad, etc) is a waste.

I believe wizard can live without X. We should feel ashamed to fiddle with crappy mouse.

I also use xmodmap sometime but it doesn't work on console. I prefer loadkeys for simple remap.

Real wizards may also write their own environment in which they would feel the most comfortable for themselves.

I wouldn't call myself a wizard but I can force myself to live in console environment if I have to. Started linux by learning the ways of CLI and having to deal with a broken distro along with ancient hardware has made me somewhat less dependent on GUI unless I want to "spoil" myself for a bit.

loadkeys was also mentioned by HaaTa as well, though I guess my desires were much more complex and it seems more and more that the end result is that I maybe forced to either learn xkb or make use of your firmware along with a custom board for my HHKB. Maybe even both!  )

Whilst you are here, how is TMK board going? I am still eager to buy that TMK firmware (for HHKB) off you! Teensy board may also work but I rather a more elegantly designed replacement controller board for HHKB (ironically considering that your controller board looks like an ideal "drop-in" replacement).

[terran5992]

Woah thats a huge wall of text D:

[osi]

KDE was always my favorite for the bloated desktop environment. Never liked GNOME all that well.

It's dissapointing to hear flux had issues. That was my go to. Tried out icewm, blackbox and others and always went back to flux.

What about the idea of having two dresktop environments? Get a functioning setup with the keyboard working as intended and just hop back into KDE when you want to show off the visuals.

The idea definitely shaves off points from the presentation factor though-- simply because you'd have to be prepared ahead of time. Switching environments is a buzz kill to because of the waiting period.

There's also dual booting or having a VM up but still that has obvious drawbacks.

Keep digging though. You'll get something working soon enough.

[tuxsavvy]

Woah thats a huge wall of text D:

Making the most use out of single post. No point in writing mulitple responses and being a post ******** (you know what I meant). To each their own really. 

KDE was always my favorite for the bloated desktop environment. Never liked GNOME all that well.

It's dissapointing to hear flux had issues. That was my go to. Tried out icewm, blackbox and others and always went back to flux.

What about the idea of having two dresktop environments? Get a functioning setup with the keyboard working as intended and just hop back into KDE when you want to show off the visuals.

The idea definitely shaves off points from the presentation factor though-- simply because you'd have to be prepared ahead of time. Switching environments is a buzz kill to because of the waiting period.

There's also dual booting or having a VM up but still that has obvious drawbacks.

Keep digging though. You'll get something working soon enough.

Yeah for some reason I couldn't resist going back to KDE, had played with KDE a long while ago and now on what was once a relatively modern machine I couldn't resist transitioning back to KDE for a few reasons.

I think I have lightly tinkered with both ice and black but I really didn't do much within the said environment. In my opinion theres almost always something missing within each DE/WM (at least for the ones I have tried). It is either eye candy that one wants or lightweight with easy access to console. Something almost always is missing somewhere.

Ultimately I like to have two or more X instances running on the same machine however I can't even switch between virtual terminals.  . Virtual machines are nice but suffers even more of a lag when you try leaving the virtual machine running in the background for more than a day. At least it did on my machine so it is not viable. Apart from that both virtual machines along with dual/multibooting would cause delays of somesort. Earlier preparations can counteract that but it doesn't work well in my case. I get some unexpected visitors. 

Right now my only answers are either xkb or hasu's TMK board and firmware. Maybe even both, at least I am content now that I have settled in for a hack which works without much issue (apart from not being able to switch between virtual terminals and the X session). I guess I can sort of live without it considering yakuake is giving me some "breathing space" within GUI realm.

[TacticalCoder]

Hey tux,

I've got a question for you: can you confirm, say using xev, that the two physical keys respectively at the left and the right of the spacebar do send different keycodes? I'm on an HHKB Pro 2 but I need a smaller (narrower) spacebar because I hit the key at the left of the spacebar with my left thumb and the key at the right of my spacebar with my right thumb (and, no, I'm not gonna use the SpaceFn layout which turns spacebar into a modifier: I like my modifiers : )

I'm using the Awesome WM, a custom layout modified using XKB and a "regular" HHKB Pro 2, so I can't help you much but I do plan on buying a HHKB JP soon 

[TacticalCoder]

Ultimately I like to have two or more X instances running on the same machine however I can't even switch between virtual terminals.

What do you mean? Keyboard issues?

I very often have a second user account which I use to launch a xvncserver which I display from one of my Awesome workspace using vncviewer. That way I do have two X instances running: the real one and a "fake" one (it's vnc, but ultra-fast seen that it's local). Back in the days I used to launch several instances of X but I find switching from a workspace to another workspace running a vncviewer fullscreen is faster than switching to another X session (at least in the past it required some graphics cards switching / reinitialization or whatever... Don't know nowadays seen that I don't do it anymore).

[tuxsavvy]

Hey tux,

I've got a question for you: can you confirm, say using xev, that the two physical keys respectively at the left and the right of the spacebar do send different keycodes? I'm on an HHKB Pro 2 but I need a smaller (narrower) spacebar because I hit the key at the left of the spacebar with my left thumb and the key at the right of my spacebar with my right thumb (and, no, I'm not gonna use the SpaceFn layout which turns spacebar into a modifier: I like my modifiers : )

I'm using the Awesome WM, a custom layout modified using XKB and a "regular" HHKB Pro 2, so I can't help you much but I do plan on buying a HHKB JP soon 

I was about to say that the keys on either sides of HHKB Pro2 are the same until you mentioned you plan on buying HHKB JP. HHKB JP as one can evidently see that the legends on the keys are quite different. With my xmodmap configuration shown in my first post I shall post the results of xev using that config as mentioned.

My HHKB JP is setup in Mac mode so keep that in mind. I think even if left in Windows mode the results would more or less be the same (keycodes-wise) minus media keys and the power key.

Code: [Select]

KeyPress event, serial 37, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939245851, (135,55), root:(135,848),
    state 0x10, keycode 49 (keysym 0xff2a, Zenkaku_Hankaku), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939245979, (135,55), root:(135,848),
    state 0x10, keycode 49 (keysym 0xff2a, Zenkaku_Hankaku), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939247323, (135,55), root:(135,848),
    state 0x10, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939247395, (135,55), root:(135,848),
    state 0x10, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939247893, (135,55), root:(135,848),
    state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939247979, (135,55), root:(135,848),
    state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939249347, (135,55), root:(135,848),
    state 0x10, keycode 102 (keysym 0xff22, Muhenkan), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939249459, (135,55), root:(135,848),
    state 0x10, keycode 102 (keysym 0xff22, Muhenkan), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939249987, (135,55), root:(135,848),
    state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XmbLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939250083, (135,55), root:(135,848),
    state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939251163, (135,55), root:(135,848),
    state 0x10, keycode 100 (keysym 0xff23, Henkan_Mode), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939251235, (135,55), root:(135,848),
    state 0x10, keycode 100 (keysym 0xff23, Henkan_Mode), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939251467, (135,55), root:(135,848),
    state 0x10, keycode 101 (keysym 0xff27, Hiragana_Katakana), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939251563, (135,55), root:(135,848),
    state 0x10, keycode 101 (keysym 0xff27, Hiragana_Katakana), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939251827, (135,55), root:(135,848),
    state 0x10, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939251939, (135,55), root:(135,848),
    state 0x18, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939254020, (135,55), root:(135,848),
    state 0x10, keycode 113 (keysym 0xff51, Left), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939254107, (135,55), root:(135,848),
    state 0x10, keycode 113 (keysym 0xff51, Left), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939254371, (135,55), root:(135,848),
    state 0x10, keycode 116 (keysym 0xff54, Down), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939254491, (135,55), root:(135,848),
    state 0x10, keycode 116 (keysym 0xff54, Down), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939254619, (135,55), root:(135,848),
    state 0x10, keycode 114 (keysym 0xff53, Right), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 939254723, (135,55), root:(135,848),
    state 0x10, keycode 114 (keysym 0xff53, Right), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Fn keys themselves obviously does not send out any keycodes so I'll also post the xev output with my left Fn key held down. The dedicated arrow keys have extra functions accessible on the Fn layer whilst the rest of the keys on the same row as the spacebar does not have any extra functions:

Code: [Select]

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940005556, (139,-56), root:(139,737),
    state 0x10, keycode 49 (keysym 0xff2a, Zenkaku_Hankaku), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940005636, (139,-56), root:(139,737),
    state 0x10, keycode 49 (keysym 0xff2a, Zenkaku_Hankaku), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940006132, (139,-56), root:(139,737),
    state 0x10, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940006244, (139,-56), root:(139,737),
    state 0x10, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940006996, (139,-56), root:(139,737),
    state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940007100, (139,-56), root:(139,737),
    state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940007580, (139,-56), root:(139,737),
    state 0x10, keycode 102 (keysym 0xff22, Muhenkan), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940007668, (139,-56), root:(139,737),
    state 0x10, keycode 102 (keysym 0xff22, Muhenkan), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940007972, (139,-56), root:(139,737),
    state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XmbLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940008052, (139,-56), root:(139,737),
    state 0x10, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940008499, (139,-56), root:(139,737),
    state 0x10, keycode 100 (keysym 0xff23, Henkan_Mode), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940008572, (139,-56), root:(139,737),
    state 0x10, keycode 100 (keysym 0xff23, Henkan_Mode), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940008964, (139,-56), root:(139,737),
    state 0x10, keycode 101 (keysym 0xff27, Hiragana_Katakana), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940009036, (139,-56), root:(139,737),
    state 0x10, keycode 101 (keysym 0xff27, Hiragana_Katakana), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940009444, (139,-56), root:(139,737),
    state 0x10, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940009532, (139,-56), root:(139,737),
    state 0x18, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940012652, (139,-56), root:(139,737),
    state 0x10, keycode 119 (keysym 0xffff, Delete), same_screen YES,
    XLookupString gives 1 bytes: (7f) ""
    XmbLookupString gives 1 bytes: (7f) ""
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940012756, (139,-56), root:(139,737),
    state 0x10, keycode 119 (keysym 0xffff, Delete), same_screen YES,
    XLookupString gives 1 bytes: (7f) ""
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940013124, (139,-56), root:(139,737),
    state 0x10, keycode 134 (keysym 0xffec, Super_R), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940013252, (139,-56), root:(139,737),
    state 0x10, keycode 134 (keysym 0xffec, Super_R), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940262940, (533,-208), root:(533,585),
    state 0x10, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2600001,
    root 0x1e1, subw 0x0, time 940263052, (533,-208), root:(533,585),
    state 0x14, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False
Not of a big drama if you can't help, I guess it puts more nails in my coffin that I am alone on this case hahaha.

Ultimately I like to have two or more X instances running on the same machine however I can't even switch between virtual terminals.

What do you mean? Keyboard issues?

I very often have a second user account which I use to launch a xvncserver which I display from one of my Awesome workspace using vncviewer. That way I do have two X instances running: the real one and a "fake" one (it's vnc, but ultra-fast seen that it's local). Back in the days I used to launch several instances of X but I find switching from a workspace to another workspace running a vncviewer fullscreen is faster than switching to another X session (at least in the past it required some graphics cards switching / reinitialization or whatever... Don't know nowadays seen that I don't do it anymore).

I personally don't believe it is keyboard issues. It seems somewhere else is broken with X or KDE. Normally virtual terminals are accessible via Ctrl+Alt+F{1-6,8-12} and X normally sits on Ctrl+Alt+F7. It is just that no matter on which keyboard I use (full sized or HHKB) I can no longer access virtual terminals thereby making my X seems like my only "visible screen". It was never to be intended to be setup like this as it was working fine when I was using some rubber dome keyboard to setup my machine (installing Archlinux that is). It was still working right up until I started using HHKB JP and remapping keys. That is where everything became a mess, no shortcuts, certain keys not working, no access to virtual terminals (it was working intermittently on certain keys).

Yeah the VNC is another way to set it up but right now such case seems a little unlikely and I used to recall VNC was really sluggish. So throwing KDE in there it may make it really sluggish so much to give others poor impression of what linux is meant to be.

[TacticalCoder]

Thanks a lot for the xev output.  I think I'm gonna buy the HHKB JP  and give it a try...

Regarding the HHKB Pro 2: despite the two keys at the right and left of the spacebar having the exact same symbols printed on them, they do send different keycodes. On every keyboard I owned I always used one as Alt and the other as AltGr. But seen that the HHKB JP is so different, I was wondering if maybe there was a gotcha 

Normally virtual terminals are accessible via Ctrl+Alt+F{1-6,8-12} and X normally sits on Ctrl+Alt+F7

Yup,  by default the first is on Ctrl+Alt+F7.  That said on my setup, virtual text terminals stop at F6 by default (there's nothing at first on CTRL+Alt+F8)...   And the second X, if any, is on Ctrl+Alt+F8 etc. (say if I started it with "startx -- :1", which I used to typically do after doing CTRL+Alt+F2).

(Pretty much a stock Debian here)

It was still working right up until I started using HHKB JP and remapping keys. That is where everything became a mess, no shortcuts, certain keys not working, no access to virtual terminals (it was working intermittently on certain keys).

I do all my remapping using xkb. For years I used xmodmap but then I read that nowadays xkb is what should be used... It's not that complicated: you dump a layout which you like as a start (I took the french AZERTY layout, because it has AltGr already well configured) to an .xkb file and then you modify it to fit your need (for example I swapped Alt and AltGr and transformed the AZERTY back to QWERTY, etc.). I used the french layout as a start because I found it easier than starting from a layout which didn't have AltGr+... producing level 3 iso shift and try to add it myself.

Now I'm not recommending anyone to use my setup but, to give an example, using xbk to swap Alt and AltGr means changing exactly two lines in the .xkb config file.

I'd say that under it's Rube Goldberg-like machinery xkb is not that complicated so you may want to give it a try too.

Overall it's easy: as soon as I mess something, I simply call the last working setup, say "xkbcomp ~/blablabla.xkb $DISPLAY" and try something else.

I do still use xmodmap to check (and sometimes clear / modify) modifiers (xmodmap -pm).

Maybe you could try starting from the japanese layout and then mod it to your will? (I take it that it's what I'm gonna do once I get my HHKB JP: all the modifiers should be correctly configured if I start from the japanese layout, which I'd then "simply" transform back to regular QWERTY).

Yeah the VNC is another way to set it up but right now such case seems a little unlikely and I used to recall VNC was really sluggish. So throwing KDE in there it may make it really sluggish so much to give others poor impression of what linux is meant to be.

Over the network I find VNC so slow as to be nearly unusable... But locally I think it's really fine: I've got a 1920x1200 monitor and just tried to play 3 movies simultaneously inside the Xvnc and viewing them in my "real X" (the one a :0) using vncviewer.  Seems fine...  I'm not sure KDE or any other WM would change much: vnc is VM agnostic I think ^ ^

My machine is not a speed daemon: just a Core i5-3450s (low TDP, pretty quiet) with 4GB of RAM.

You could always try it and see what gives      (for what it is worth my heavy-remapped setup seems to work fine inside the vncviewer: so apparently no keymappings / shortcuts issues that would be due to VNC)

[hasu]

Whilst you are here, how is TMK board going? I am still eager to buy that TMK firmware (for HHKB) off you! Teensy board may also work but I rather a more elegantly designed replacement controller board for HHKB (ironically considering that your controller board looks like an ideal "drop-in" replacement).

In next revision PCB I'll add initial support of HHKB JP. But I can't update firmware to support JP 'cause I dont' have it in hand. But some JP user is working on firmware job now. If you are interested watch my controller thread.

[Pro XKB]

Here is a bug from the KDE bugzilla that seems related to the issue:

https://bugs.kde.org/show_bug.cgi?id=318904

Looking at your xev output, the Mod2 modifier is set (state 0x10). As far as I understood, if you have no Num_Lock key, applications do not understand the meaning of Mod2, and might behave strangely.

[tuxsavvy]

Thanks a lot for the xev output.  I think I'm gonna buy the HHKB JP  and give it a try...

Regarding the HHKB Pro 2: despite the two keys at the right and left of the spacebar having the exact same symbols printed on them, they do send different keycodes. On every keyboard I owned I always used one as Alt and the other as AltGr. But seen that the HHKB JP is so different, I was wondering if maybe there was a gotcha 

I thought back to the HHKB Pro2 keyboard the moment how you said about how the there is Alt and AltGr. I suppose Alt_L and Alt_R have their own individual keycodes hence one could easily remap either of them as AltGr or as a normal Alt_{L,R} button respectively. It is understandable that there is a need to have AltGr in notable ISO keyboard layouts as it allows one to input region specific letters such as "€" for instance.

Not exactly an expert on standards but I somehow do believe the JIS layout loosely follows the ISO layout. The Enter key is still shaped like the letter "7" whilst I guess the left shift key length is swapped with right shift key as in instead of having an extra key before the letter "z" on a regular QWERTY layout for ISO keyboard, there is an extra key before the right shift key for the JIS layout. At least for the HHKB JP the case is like this. The backspace key length is shortened to accomodate an extra key in between. The bottom row, well that is evident. shortened spacebar to accomodate extra modifiers specific to the Japanese language.

Some interesting links that I thought it was worthy to point out but you may probably have been aware of this:

• http://deskthority.net/wiki/ANSI_vs_ISO
• http://deskthority.net/wiki/ANSI_vs_JIS

I suppose it would be really weird if both Alt keys for instance shared the same keycode whilst placed on different sides of the spacebar. Conversely I can see your point of concern is. However I personally do believe there probably are not many keyboards out there that would have two Alt sharing the same keycode whilst using either ISO or JIS layout.

Normally virtual terminals are accessible via Ctrl+Alt+F{1-6,8-12} and X normally sits on Ctrl+Alt+F7

Yup,  by default the first is on Ctrl+Alt+F7.  That said on my setup, virtual text terminals stop at F6 by default (there's nothing at first on CTRL+Alt+F8)...   And the second X, if any, is on Ctrl+Alt+F8 etc. (say if I started it with "startx -- :1", which I used to typically do after doing CTRL+Alt+F2).

(Pretty much a stock Debian here)

Yup most distros and I would probably go as far as saying that also most basic setups would have nothing past Ctrl+Alt+F7. There are some distros that probably would make use of the spare terminals such as SuSE or IPCop outputting kernel logs through Ctrl+Alt+F12. SuSE would probably use Ctrl+Alt+F11, and even Ctrl+Alt+F10 for stuff like lsmod output (to be monitored if I remember correctly) and can't recall what the other blank terminal was used for. I like to point out here that SuSE is no longer called as such, some people may like to kindly refer them as OpenSUSE, but when I used SuSE it was more of a commercial variant (it was not exactly free, they had Free and Pro versions). I haven't properly tried OpenSUSE so I don't know if the same traditions of making use of those other terminals still carried over from SuSE.

I have setup my Archlinux to be quite similar in that respect, making use of some of the blank terminals. dmesg on the last one as usual, iptables output on one and some other thing I was running on F10 but I can't remember now (lol).

That said it would still leave F8 and F9 blank in which I could easily spawn an X session or two to fill those gaps. However I can't access them so it makes the exercise rather moot.

It was still working right up until I started using HHKB JP and remapping keys. That is where everything became a mess, no shortcuts, certain keys not working, no access to virtual terminals (it was working intermittently on certain keys).

I do all my remapping using xkb. For years I used xmodmap but then I read that nowadays xkb is what should be used... It's not that complicated: you dump a layout which you like as a start (I took the french AZERTY layout, because it has AltGr already well configured) to an .xkb file and then you modify it to fit your need (for example I swapped Alt and AltGr and transformed the AZERTY back to QWERTY, etc.). I used the french layout as a start because I found it easier than starting from a layout which didn't have AltGr+... producing level 3 iso shift and try to add it myself.

Now I'm not recommending anyone to use my setup but, to give an example, using xbk to swap Alt and AltGr means changing exactly two lines in the .xkb config file.

I'd say that under it's Rube Goldberg-like machinery xkb is not that complicated so you may want to give it a try too.

Overall it's easy: as soon as I mess something, I simply call the last working setup, say "xkbcomp ~/blablabla.xkb $DISPLAY" and try something else.

I do still use xmodmap to check (and sometimes clear / modify) modifiers (xmodmap -pm).

Maybe you could try starting from the japanese layout and then mod it to your will? (I take it that it's what I'm gonna do once I get my HHKB JP: all the modifiers should be correctly configured if I start from the japanese layout, which I'd then "simply" transform back to regular QWERTY).

I have sort of started looking briefly at xkb after being referred to the same thing twice by two people (and now with you included that makes three haha). After briefly loosely following Archwiki on xkb and dumping the current configuration I started briefly browsing over the information to see if I can get a better meaning of it all. It turns out that functions were abbreviated.

Here is an example of what I mean:

Code: [Select]

    <RCTL> = 105;
    <KPDV> = 106;
    <PRSC> = 107;
    <RALT> = 108;
    <LNFD> = 109;
    <HOME> = 110;
versus...

Code: [Select]

keycode 105 = Control_R NoSymbol Control_R
keycode 106 = slash NoSymbol slash
keycode 107 = Print Sys_Req Print Sys_Req
keycode 108 = Alt_R NoSymbol Alt_R
keycode 109 = Linefeed NoSymbol Linefeed
keycode 110 = Home NoSymbol Home

Although not having sunk in deeply on the xkb config but having noticed that I guess it looks like I'll have to learn and adhere to the new layout should I want to use xkb.

HaaTa also gave me a hint on ISO_Shift_Level_3 as a hint when dealing with xmodmap and multiple layouts when trying to alleviate the limited number of modifiers (via mod{1-5}) as there are more Shift key themselves have more than one level. Though ultimately I guess I need to move off xmodmap and xkb.

Yeah I know it is not exactly complicated, but just the new syntaxes sort of throw me off I guess. xkb does seem to be far more flexible than dealing with xmodmap when it comes to adding language groups I have sort of noticed. That was something that HaaTa pointed out as well in which I guess that would be one other way for me to look at things.

My original plan with my xmodmap setup was to add for starters HHKB JP layout which is basically the Japanese layout as indicated on the keyboard. That was basically sorted out as what you have indicated. For me there are no plans to really slowly make my HHKB JP layout to be more QWERTY. Instead I plan to ultimately add real Japanese outputs via something like this (obviously this will never work with xmodmap but I am just making a mock up image of my goal):

Code: [Select]

keycode 34 = a A ち チ
In other words I am basically forcing Japanese input without the need for me to strictly go through IME route. There is nothing wrong with IME (once you get it working right) but before that time, it can be a pain when some of the programs fails to accept IME input and the need to press a few keys to enable Japanese language input for instance.

I may probably have to do the same thing as well for Chinese (yay! more fun...)

Yeah the VNC is another way to set it up but right now such case seems a little unlikely and I used to recall VNC was really sluggish. So throwing KDE in there it may make it really sluggish so much to give others poor impression of what linux is meant to be.

Over the network I find VNC so slow as to be nearly unusable... But locally I think it's really fine: I've got a 1920x1200 monitor and just tried to play 3 movies simultaneously inside the Xvnc and viewing them in my "real X" (the one a :0) using vncviewer.  Seems fine...  I'm not sure KDE or any other WM would change much: vnc is VM agnostic I think ^ ^

My machine is not a speed daemon: just a Core i5-3450s (low TDP, pretty quiet) with 4GB of RAM.

You could always try it and see what gives      (for what it is worth my heavy-remapped setup seems to work fine inside the vncviewer: so apparently no keymappings / shortcuts issues that would be due to VNC)

My machine is ancient hahaha. Core(TM)2 Duo E6750 with 8GB DDR2-SDRAM. Though I haven't tried running VNC locally so I guess it maybe interesting if and when the time comes.

Whilst you are here, how is TMK board going? I am still eager to buy that TMK firmware (for HHKB) off you! Teensy board may also work but I rather a more elegantly designed replacement controller board for HHKB (ironically considering that your controller board looks like an ideal "drop-in" replacement).

In next revision PCB I'll add initial support of HHKB JP. But I can't update firmware to support JP 'cause I dont' have it in hand. But some JP user is working on firmware job now. If you are interested watch my controller thread.

Cool! I cannot wait. I have been watching and bookmarked a whole bunch of links relating to your TMK project though I couldn't recall much new updates on the TMK PCB itself apart from some people got the board off you and apparently you ran out and have to buy more or something.

Yeah I know you don't have HHKB JP haha, real people don't need HHKB JP just as many Youtube videos I have seen that not many Japanese people themselves uses HHKB JP. The idea of me purchasing HHKB JP was to sort of kill as many birds as I can with one stone. Inevitably that came with lots of catches but I guess in either way I will need to face up with them. As the old Japanese saying goes,"七転び八起き" (Literal English translation: seven fall down, eight stand up. Translated to proper English: Fall down seven times, stand up eigth time. In other words persistence/perseverance pays off.)

I am not good at programming but I'll try to help out where I can on your project. I also tried reaching you on IRC but you don't speak much on there hahaha (besides my handle on forum is different on IRC but that is another story..). Anyway I am still very interested in your project regardless, a firmware replacement that will ultimately never require one to configure their machine/computer like hell.

Here is a bug from the KDE bugzilla that seems related to the issue:

https://bugs.kde.org/show_bug.cgi?id=318904

Looking at your xev output, the Mod2 modifier is set (state 0x10). As far as I understood, if you have no Num_Lock key, applications do not understand the meaning of Mod2, and might behave strangely.

Welcome to the geekhack forums! Thanks for the link as well.

The link does contain some useful information, notably in the case of where "Martin Gräßlin" is noted. I was trying to get a hold of him on IRC but he comes on different hours of the day and only for a short time (thankyou very much timezones...) but now I know the issue is not specific to KWin but some other component.

Anyway it seems that in order for me to try and replicate the issue I will need to first migrate onto xkb at any given rate or I might get frowned for still using the relic xmodmap (lol). On my currently working config, it shows as state: 0x0 for Alt and 0x8 for Tab. I have not swapped the Tab key yet but I could try that. Though again might be better if I first migrate onto xkb then try disabling the lock keys (except for Caps_Lock which I do have a key for but no LED light to indicate whether or not it is on). Thinking of it I do believe at the time of the testing, my full sized keyboard did have the Num_Lock LED on when I was testing out the keys for TacticalCoder. The state 0x0 is now with numlock off. Trying with it on, an extra digit (1) has been added. So instead of 0x0 for Alt with numlock off it becomes 0x10 when it is on, same thing with Tab key, 0x18 instead of 0x8.

The strange thing conversely is that had I not define Num_Lock key (along with Scroll_Lock, I do not know which one fixes the issue. Most  likely Num_Lock as I did see the spike in CPU usage via gkrellm). The shortcuts does not work for most of the stuff on the global level as well as yakuake. Stuff like Alt+F2 does not bring down the Krunner and when pressing F12 it does not bring the yakuake screen down. Ironically pressing the F12 key when there is no Num_Lock set will print out "4~" on the terminal but won't hide yakuake.

The issue seems to be heavily tied on the Num_Lock issue. Absence of Num_Lock being defined makes shortcuts on certain things behave  erratically conversely they stop behaving erratically when Num_Lock key gets artificially defined and bound.

I have also tried using numlockx to turn the numlock on and off, even if I went and disabled my other keyboard (a full sized keyboard with all the lock keys as well as LED on all the lock keys) numlockx does not report any issues. I disabled my other keyboard via xinput disable <device name>. Also no issues with shortcuts regardless if numlock was set to either on or off.

[tuxsavvy]

A tiny bit of necro bump on this thread.

I have found out the keycodes to switch between console and X11 session. Switching between KDE4 and TWM does help I guess. My KDE4 is now very buggy (it would load fine but try running a few programs and somehow X11 would freeze). Without binding console keys for instance, switching to a console would have been virtually impossible (rebooting would be ensured). Also the initial post was updated to reflec the new changes.

The issue still remains (artificial Num_Lock bind) and for now I am using XFCE instead to get around KDE4's woes.