Keyboard localization to Korean

[hylo]

Hi, all!
I'm glad to present Kindle Korean keyboard(kingul) for you.

Spoiler:

Kingul is a compound word of 'Kindle' and 'Hangul', name of the Korean alphabet. Since PW3 doesn't support Korean keyboard, I made one for myself. Unlike the other languages, Korean alphabet can be composed with some of its own to make another character(syllable) with a new unicode value.

e.g. 한(U+D55C) = ㅎ(U+1112), ㅏ(U+1161), ㄴ(U+11AB)
The display sequence on the screen is ㅎ -> 하(another composed character) -> 한. In other words, it needs a postprocessing after a key is typed. This hack provides you such a postprocessing on Kindle PW3 device.

This is an open source project and curretnly being managed on github(https://github.com/hylo926/kingul). Since it captures keyboard inputs and can send arbitrary input, it would be useful to someone who wants to make a feature like snippet or something.


What Does It Do?:

Spoiler:

When you type a key on the screen, it sends to the appropriate window an event that indicates the key is pressed or released. This hack continoulsy tries to catch a currently focused window, peeks the key event, does the postprocessing by entering or deleting characters.

Latest Updates (08/31/2016):

Spoiler:

Implemented KUAL menu.

INSTALL:

Spoiler:

Prerequisites: Jailbroken PW3 device, KUAL + MRPI Installer

Put the install.bin file to Kindle/mrpackages and run it with MRPI helper

UNINSTALL:

Spoiler:

Put the uinstall.bin file to Kindle/mrpackages and run it with MRPI helper

NOTES & TROUBLESHOOTING:

Spoiler:

(1) Suddenly, vowels and consonants are separated on the screen
: Restart the kingul.(KUAL -> Kingul -> Restart kingul)
(2) There's no Kokrean in Keyboard setting.
: Choose keyboard selection on KUAL menu (KUAL -> Kingul -> Toggle keyboard selection)

Changelog:

Spoiler:

08/31/2016 - v0.5 KUAL menu
08/30/2016 - v0.4 Support PW2 and Voyage
08/29/2016 - v0.3 Lowered the CPU usage

Got the basic idea from
https://www.mobileread.com/forums/sho...5&postcount=28
Thanks you, baf.

Original Post:

Spoiler:

Hi all,
I'm trying to localize default keyboard to Korean on jailbroken PW3 with 5.8.1 FW.
Since the most languages are supported now, or easily be done with pre-existing localization files inside /usr/share/keyboard (including Korean keymap), regarding old threads are seemed to be abandoned.
If it's not, I'm sorry and please let me know the thread that I can ask for a help.

First of all, I succeeded to change the keyboard layout and print Korean letters. I copied 'ko' folder from /usr/share/keyboard, which contains Korean keymap files, into /var/local/keyboard and modified file names, and then mounted to some other supported keyboard. For example, change the filename from ko-1448x1072.keymap.gz to ru-1448x1072.keymap.gz and then by using 'mount --bind' to bind /var/local/keyboard/ko into /usr/share/keyboard/ru.

Most of languages are covered enough with so far. But the problem is Korean character(called Hangul) is distinguished from other characters because each letter should be assembled or composed with other letters to make one complete character. For example, 한(U+D55C) is composed of 3 letters: ㅎ(U+1112), ㅏ(U+1161), ㄴ(U+11AB). The display sequence on the screen is ㅎ -> 하(another composed character) -> 한. But now they're just displayed as three separate characters on the screen(ㅎㅏㄴ). In conclusion, it needs some kind of post-processing after a key is typed.

At first, I thought binary files inside keyboard folder(*.kdb, *.ldb, utils.so) are something to do with it. But after a few experiments, I concluded that it's only related to input suggestion.

And then I found that Japanese keyboard has a similar post-processing system. Basically, it's a system that converts Romaji to Hiragana according to hiragana_rules.txt which I found inside 'ja' folder. If you type 'a' or 'ha' it converts them into appropriate Japanese character. In the text file 'hiragana_rules.txt', there is a bunch of such rules. So I thought it would be possible to post-processing Korean letters by tweaking these rules. But again, this text file seems irrelevant to current keyboard behavior. It says "These rules replace the default ICU behavior" but it was not. I guess these rules have been compiled and exist somewhere else inside the device in a binary form.

Finally, I decided to hook the keyboard and add some post processing on it. But I have no idea where to start. And also, I'm not fully aware of the software stack of PW3 because I started this since yesterday. I've searched around this forum but haven't found the useful information yet. So it would be a great help if someone could give me some hints or suggest an easier way.

[hylo]

It was libpredict.so that is required to convert Romaji to Hiragana which I least suspected... I changed one of the letters in Korean keymap to 'a' and when I typed it converted into Hiragana although device had soft reset soon after. I assume it's a soft reset because SSH connection was not disconnected during 'the boy under the tree' screen with a progress bar.

[root@kindle ja.ko]# ldd libpredictor.so
/usr/lib/libenvload.so (0x40138000)
libwlf.so => /usr/lib/libwlf.so (0x40056000)
libicuuc.so.50 => /usr/lib/libicuuc.so.50 (0x401d3000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x402fc000)
libc.so.6 => /lib/libc.so.6 (0x403f4000)
libiwnn.so => /usr/lib/libiwnn.so (0x400d1000)
libicudata.so.50 => /usr/lib/libicudata.so.50 (0x40522000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40141000)
libdl.so.2 => /lib/libdl.so.2 (0x40161000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x4123b000)
libm.so.6 => /lib/libm.so.6 (0x41306000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40077000)
/lib/ld-linux.so.3 (0x400a9000)

libicudata.so is presumed to be the one I'm looking for. I'm going to find some patterns of unicode of Japanese characters inside that library. International Components for Unicode(ICU) project is an open source project. (http://site.icu-project.org/)

Maybe I can build my own libicudata.so.

[knc1]

Have you checked the Amazon source code archive for your device's 5.8.1?
It may have the source for that library in it (if it is GPL, that is all they release).

[hylo]

Originally Posted by knc1

Have you checked the Amazon source code archive for your device's 5.8.1?
It may have the source for that library in it (if it is GPL, that is all they release).

Oh, good idea. Haven't thought about that.
I looked up their 5.8.1 source code, but unfortunately, there wasn't.
By the way, it's ICU License rather than GPL and I couldn't find any clause that the user have to make their source code public. The ICU project is somewhat bulky so building it appropriately seems a lot of work..

[hylo]

Ok, so I've implemented Korean keyboard with postprocessing during the weekend. The basic idea is intercepting the X11 event related to keyboard sent to X11 windows generated from /usr/bin/kb and tweaking the unicodes within the range of Korean characters. So, theoretically, it shouldn't disturb or interrupt other language keyboard inputs and processes. I think it's working well in that perspective.

Anyway, I'm going to make the source code public. And I'd like to release it in a package form with a help of kindletool. I'm searching this forum for how this tool works or at least the usage of this tool.

Since my kindle has GLIBC of version 2.19(PW3 5.8.1) and I had to use it for building binaries instead of default 2.12, I'm worrying it won't work on other versions of firmware.

[knc1]

The symbols your program references are versioned and include what revision glibc they first appeared in.

So list them.
Probably nm would be the tool to use.
For details:

man nm

or

man --help

Let me guess here -
You must be most familar with one of those operating systems where the help files are an extra-cost option.

[zxczxc]

Congratulations on getting your keyboard working, that sounded a bit difficult!

[NiLuJe]

As @knc1 mentioned, examining the symbol table of your resulting binary should be enough to make sure you're not hitting ABI issues.

I'm personally a fan of readelf for that job, which I find more user-friendly than nm .

[hylo]

Originally Posted by zxczxc

Congratulations on getting your keyboard working, that sounded a bit difficult!

Thanks I hope this helps many.

Originally Posted by NiLuJe

As @knc1 mentioned, examining the symbol table of your resulting binary should be enough to make sure you're not hitting ABI issues.

I'm personally a fan of readelf for that job, which I find more user-friendly than nm .

Yes, readout from readelf was much more friendly for me, too. Moreover, I figured out later that '-D' option is needed for nm to print out dynamic symbol table when I'm not accessible to this toolchain. So, here is my binary's dynamic symbol table from readelf.

    Symbol table '.dynsym' contains 31 entries:
    Num:    Value  Size Type    Bind   Vis      Ndx Name
    0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
    1: 00000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTab
    2: 00000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
    3: 00000000     0 NOTYPE  WEAK   DEFAULT  UND _Jv_RegisterClasses
    4: 00000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable
    5: 00021ae0     0 NOTYPE  GLOBAL DEFAULT   23 _bss_end__
    6: 00000000     0 FUNC    GLOBAL DEFAULT  UND XGetWindowAttributes
    7: 000116ec     0 FUNC    GLOBAL DEFAULT   13 _fini
    8: 00021ad4     0 NOTYPE  GLOBAL DEFAULT   23 __bss_start__
    9: 000106e4     0 FUNC    GLOBAL DEFAULT   10 _init
    10: 00021ad4     0 NOTYPE  GLOBAL DEFAULT   23 __bss_start
    11: 00000000     0 FUNC    GLOBAL DEFAULT  UND XDisplayKeycodes
12: 00000000     0 FUNC    GLOBAL DEFAULT  UND abort@GLIBC_2.4 (2)
    13: 00021ae0     0 NOTYPE  GLOBAL DEFAULT   23 _end
    14: 00021ae0     0 NOTYPE  GLOBAL DEFAULT   23 __end__
    15: 00000000     0 FUNC    GLOBAL DEFAULT  UND XSelectInput
    16: 00000000     0 FUNC    GLOBAL DEFAULT  UND XFree
17: 00000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.4 (2)
    18: 00021ad4     0 NOTYPE  GLOBAL DEFAULT   22 _edata
19: 00000000     0 FUNC    GLOBAL DEFAULT  UND usleep@GLIBC_2.4 (2)
    20: 00000000     0 FUNC    GLOBAL DEFAULT  UND XOpenDisplay
    21: 00000000     0 FUNC    GLOBAL DEFAULT  UND XCheckWindowEvent
    22: 00000000     0 FUNC    GLOBAL DEFAULT  UND XSendEvent
23: 00000000     0 FUNC    GLOBAL DEFAULT  UND puts@GLIBC_2.4 (2)
    24: 00021ae0     0 NOTYPE  GLOBAL DEFAULT   23 __bss_end__
    25: 00000000     0 FUNC    GLOBAL DEFAULT  UND XChangeKeyboardMapping
    26: 00000000     0 FUNC    GLOBAL DEFAULT  UND XFetchName
27: 00000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.4 (2)
    28: 00000000     0 FUNC    GLOBAL DEFAULT  UND XLookupKeysym
    29: 00000000     0 FUNC    GLOBAL DEFAULT  UND XGetInputFocus
30: 00000000     0 FUNC    GLOBAL DEFAULT  UND raise@GLIBC_2.4 (2)

It seems that GLIBC 2.4 is the only library that version checking is needed. And it's much lower than 2.12 or 2.19. So, I carefully assume that at least this binary would be fine with the past firmware versions barring the system conf files I modified.

Thank you!

[knc1]

That is indeed what it means
"GLIBC version 2.4 OR MORE RECENT"

[hylo]

Originally Posted by knc1

That is indeed what it means
"GLIBC version 2.4 OR MORE RECENT"

Thank you for confirm.