Site Tools


hardwarerelated:hangul_keyboard

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
hardwarerelated:hangul_keyboard [2016/08/17 07:28] – [What is this about?] chrishardwarerelated:hangul_keyboard [2022/11/13 12:06] (current) – external edit 127.0.0.1
Line 1: Line 1:
 +===== What is this about? =====
 +I bought a keyboard in korea, with background LED and hangul on its keys. Quite cheap for this quality and LED backlight. This document my reminder for using it on linux, as the keyboard needs minor tweaking for my usage on Linux.
  
 +<code>
 +[chris@Гага́рин ~]$ lsusb
 +[..]
 +Bus 001 Device 004: ID 0c45:760a Microdia 
 +[..]
 +[chris@Гага́рин ~]$ 
 +</code>
 +
 +The keyboard is usable as is with Xorg, I just have the habit of using the right ctrl-key together with the cursor keys to change the virtual screen. When starting "xev", one sees that the right ctrl-key gets recognized by Xorg, with keycode 131. It is mapped to "Hangul" though, and windowmaker does not recognize the key when running "wmprefs".
 +
 +===== The default xorg key mappings =====
 +Executing "xev" and pressing the left and the right CTRL keys, one gets by default these mappings presented:
 +<code>
 +# left CTRL
 +KeyRelease event, serial 36, synthetic NO, window 0x1a00001,
 +    root 0xde, subw 0x0, time 197433995, (973,723), root:(974,747),
 +    state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
 +    XLookupString gives 0 bytes: 
 +    XFilterEvent returns: False
 +
 +# right CTRL
 +KeyRelease event, serial 36, synthetic NO, window 0x1a00001,
 +    root 0xde, subw 0x0, time 197399484, (465,106), root:(466,130),
 +    state 0x0, keycode 131 (keysym 0xff34, Hangul_Hanja), same_screen YES,
 +    XLookupString gives 0 bytes: 
 +    XFilterEvent returns: False
 +</code>
 +===== Notes for using the keys =====
 +  * "xev" should be used to see if keys are recognized by Xorg at all.  For example the light changing key is not recognized at all, probably only the keyboard is not carrying the data to the outside.
 +  * "xmodmap -pke > ~/.Xmodmap" can store the current mappings in a file
 +  * The following code can be used to remove the groupings of keys into the "control" group, fill it with Control_L and Control_R, and map the key with code 131 to "Control_R":
 +<code>
 +xmodmap -e "clear lock"
 +xmodmap -e "clear control"
 +xmodmap -e "add control = Control_L Control_R"
 +xmodmap -e "keycode 131 = Control_R"
 +</code>
 +  * The following is doing the mapping via xmodmap file:
 +<code>
 +[chris@Гага́рин ~]$ cat .Xmodmap 
 +clear lock
 +clear control
 +add control = Control_L Control_R
 +keycode 131 = Control_R
 +[chris@Гага́рин ~]$ 
 +[chris@Гага́рин ~]$ xmodmap ~/.Xmodmap 
 +[chris@Гага́рин ~]$ 
 +</code>
 +  * compat with ibus: I often switch with the ibus-framework between the German/English/anthy/mozc layout/input methods. With the default ibus settings, the mapping of the Hangul_Hanja got lost each time after switching to a different layout/input method. Executing "ibus-setup" and activating "Use system keyboard layout" fixes this.
 +===== see also =====
 +  * https://wiki.archlinux.org/index.php/Xmodmap