JP key support

[zoop1234]

So I had a problem with some of the keys I need to use on a 106 JP keyboard were not represented in the agent interface.
Underscore Pipe and Yen or Backslash Secondary where the keys for changing language.
I Hacked them in myself by just editing the scan codes file. ./packages/uhk-common/src/config-serializer/config-items/scancodes.json I used a different tool to find the scan codes on linux. but you can find the USB scancodes in Decimal here in section 7.1 https://web.stanford.edu/class/cs140/projects/pintos/specs/kbd/scancodes-7.html Keys I needed was 135 137 136 138 My hack to the file made the Key work, but the agent shows it as blank as I am sure I had to edit some other file to make it display something. Hope this helps someone else with the same problem.

[mondalaci]

Thanks for reporting this issue! The reason I'm surprised is because we have shipped more than 100 UHKs to Japan, yet nobody has suggested this. Why noone else needs these keys?

[zoop1234]

That I do not know. it is on all standard JP keybaords that I know of. It could be that most of the poeple buying the keyboards are actually more interested in English keyboards and use an English layout. It would be interesting to ask to find out though if there is a better solution I would love to here it. I am also still interested in the different key layout. as the keys have to be mapped to odd positions. I am happy to take a picture of my JP keyboard as well if you like. let me know what else I can provide.

[mondalaci]

Well, in any case, I better include these scancodes because they seem to be useful. For every one of the 4 scancodes, please list:

• the text that I should put into the scancode selector
• the name that should appear on the key (This should be short to fit on keys. You can use Japanese characters.)

[luteijn]

I know this sounds like a broken record by now, but once again, please consider allowing arbitrary / fantasy / custom code (sequences) to be assigned straight from agent. Even if they can only be sent via the macro engine, it will really help with these kind of cases. Anyone interested in a keyboard like the uhk is in my opinion quite likely to already have other 'non-standard' keyboards and macro software that can take advantage of these kind of things.

[zoop1234]

I can type them for you here, but might be good to look over the link I pasted above as well as it has all the keys that are different from a US keyboard and scribes the functionality of the other keys. USB OutPutFromJapaneseKeyMap OutPutFromJapaneseKeyMapWithShift 135 \ _ 137 \ |
FYI this is f]rom a Linux Keymap on OSX 137 prints the Yen character. 144 かな 145 英数

Interestingly I compared what my keyboard does vs what the keyboard from that website has and there is a difference here. The keybaord I am used to using is a Apple silver JP keybaord and it seems that the keys for changing languages are different from the default style that is written on that page. I do have a standard "buffalo" JP keyboard but I don't use it much. If you would like I can confirm what it outputs for scancodes on those keys. I do know for this Apple keyboard I do have to make sure I use the Apple keymap to make it work right with linux vs any normal JP keymap. So I guess the guy who also commented on this might have a good point. it might be nice to have an interface for entering in your own Scancodes etc.. Eitherway I am happy that I can just hack the code to make it work for me. and as it is documented here so now other people can get an Idea on what they might need to do.

THanks again.

[mondalaci]

I'm getting confused. First, you mentioned scancodes 135, 137, 136, 138, and now you mention 135, 137, 144, 145. Which are the real deal?

[luteijn]

Info at http://xahlee.info/kbd/Japan_keyboard_layouts.html might be useful to complement the information from above, in particular the names of the keys in Romaji, which seem to me to be a better choice for the labels in Agent than kana and kanji . Rest of the information on that site seems interesting too. I'm already used to using US layout to enter Japanese and Chinese, but certainly seems like having 'more real' keys available to 'go native' would be useful for people into learning other languages.

[mondalaci]

Sorry, but the referenced article is of no use for me. I need the exact scancodes, the related scancode select names, and the names to display on keys.

[zoop1234]

OK I looked into this more.
My best guess is you should just add 135 and 137 with the information I provided above. As for the other keys I'll explain 144 and 145 Are keys for switching the language you are typing in on the computer. So when you are typing in japanese you type the Phonetic letters and it converts it on screen to the correct character as you go. So these are handy. What I have found though it seems that these two keys don't seem to be part of the standard PC keyboard.(as far as I could tell) But they are part of all modern MAC keyboards. The other Keys I mentioned 138 and 136 Are part of the set of keys on a Japanese PC keyboard used to control how the input software changes the characters to the different Phonetic alphabets in Japanese as well as to change it to a Chinese character or not. So slightly differnet use cases. As a test I plugged the MAC keyboard and the PC keyboard into a Windows PC I believe it was windows 10. and Found that none of these special keys worked with it. This could be because this is an original install as English and maybe we didn't have everything setup on it. As I mostly use OSX or Linux the 144 and 145 keys I do use in both for this control. It would be kewl to have a place holder in the software, but again I have no problem hacking those in myself. But I do think the first two are important. ;)

Hope that helps. Thanks.

[zoop1234]

FYI I edited the Kanji above. I had the one from the PC keyboard so changed it to what was on the MAC keyboard as it seems to be tied to that device.

[luteijn]

Typically you need some form of support for these keys on the OS side, closely integrated (probably from factory for CJK-versions of Windows or distributions of linux targetted at Japanese that you might be more familliar with), more loosly (like separate IME(s) and/or language packs to install for Japanese or Chinese) on a 'western' version of Windows, or even something 3rd party (e.g. like when adding a stylus+digitiser board to enter kanji/hanzi by handwriting).

I usually end up having to first de-localise a new PC to make it run in English with US-ansi settings instead of German or Dutch, to make it easy to type programming symbols, and then add Chinese IMEs for my wife (uses pinyin) and parents-in-law (using wubi and handwritten-on-a-tablet). I also usually install a Japanese IME too, as I suck at Chinese but sometimes I do remember the Japanese equivalent. Without the dedicated conversion keys of a Japanese keyboard, either I need to use the mouse to change modes via on-screen buttons, or bind something like shift-shift, shift-space or alt-ctrl-whatever to act as switchers, which I, or the kids then forget about and end up accidentally pressing - setting the keyboard to corrupt/gibberish mode. #1stworldproblems of living in a multilingual environment.

[zoop1234]

So I worked with the guy on Windows and was able to enable the JP-106 keyboard properly. So on it Keys with scancode 53 for english 英数 and scancode 138 for Japanese かな Again probably my opinion as they are not consistent enough maybe leave them off till there is the ability to easily add your own custom ones. Generally there is a way the OS to change the keyboard using the mouse in the taskbar etc.

[owlowlgo]

Thanks for reporting this issue! The reason I'm surprised is because we have shipped more than 100 UHKs to Japan, yet nobody has suggested this. Why noone else needs these keys?

To contribute a data point...

I type in Japanese, but am used to "Ctrl + Space" instead of the "Hankaku/Zenkaku" key, to switch between English and Japanese. I don't even know what the following keys actually do.

| 139 | 7b | (muhenkan) |     | 138 | 79 | (henkan/zenkouho) |   | 136 | 70 | (hiragana/katakana |

I imagine folks who are not reporting this issue are used to typing Japanese on English keyboards that do not include these keys.

[zoop1234]

Yea those keys are for someone more used to typing on an older PC standard keyboard. but the other two for | _ \ are important as they are not mapped properly for a JP keyboard. or in the case of the UHK it should provide an easy way to map for people used to typing on a JP-106 keyboard.

[luteijn]

I think I've pointed out the keyboard pages at the Eindhoven university before, so the UHK team probably knows about them, but they might bean interesting read for some of the other commenters here. Japanese 106-key keyboards are discussed on https://www.win.tue.nl/~aeb/linux/kbd/scancodes-8.html :-)

A lot of the stuff on those pages is for older interfaces, for usb keyboards, like uhk, the table on https://www.win.tue.nl/~aeb/linux/kbd/scancodes-14.html might be useful. I'd like to see a way to assign all of those labeled there, if just arbitrary values is not doable.

[mondalaci]

Thanks for your useful input, guys! It's also worth to read page 57 of the USB HID Usage Tables document and the related information on page 59 and 60.

I plan to create a new "International" section at the end of the select list, and add the following entries:

• scancode:135, list name:"International \_", key text:"Int \_"
• scancode:137, list name:"International \|", key text:"Int \|"
• scancode:144, list name:"かな", key text:"かな"
• scancode 145, list name:"英数", key text:"英数"

What do you think?

[eltang]

I would advise against language-specific names for these scancodes, because other countries' keyboards may use them now or in the future. For example, 135 is used as the forward slash and question mark key on the Brazilian keyboard. The HID names for these scancodes are simply "International [1-9]", so it might be best to go with that for the time being.

[luteijn]

Besides "it's more work" and "might confuse people", is there a technical reason why you wouldn't just make all of Table 12 available (perhaps excluding the 'reserved' codes?).

Agree with @eltang to keep the names as generic as possible, I'd just take the names from Table 12, strip off keyboard and replace keypad with pad. Shorten long words remaining, e.g. "Int'l" if needed.

[mondalaci]

The reason I won't include every Table 12 scancode is because a fair number of scancodes are not ever expected to be used by users, and as you correctly assumed I don't want to confuse people.

It'd probably be useful to use generic names, but also provide specific namings. My proposal is the following:

scancode:135, list name:"International 1: JP_", key text:"Int1 JP_" scancode:137, list name:"International 3: JP|", key text:"Int3 JP|" scancode:144, list name:"Language 1: かな", key text:"Lang1 かな" scancode 145, list name:"Language 2: 英数", key text:"Lang2 英数"

The first word of the key text would always show. The rest would only show if there's enough space available.

[eltang]

As I mentioned, the specific names could confuse Brazilian layout users, and users of layouts which don’t yet exist. Plus, it’s probably best not to give preferential treatment to languages other than English unless #710 is going to be fully implemented.

[mondalaci]

I understand your reasons, yet "International 1" and its likes are overly general. I'd much rather add additional scancodes and namings upon individual requests.

[luteijn]

I'd give them generic names but make it possible to give each key a user-definable label too. Could just be a small key/value file read by agent with mappings at first, not pushed to the keyboard. Additionally, a page of hints that lists some common names of special keys used in various keyboard-localisations could be added.

Personally especially codes not normally used actually interest me, as they'd likely allow actions to be bound to them that would not conflict with hotkeys used by applications already.

[mondalaci]

A user-definable label is too much of a pain to implement, and I doubt about its usability. It'd be however useful to add scancode-specific hints to the popover eventually, but I feel that even that is slightly overkill for now.

What's your use case regarding unused scancodes? F13-F24 are already available. Why even more?

[owlowlgo]

I personally think that the optimal solution would be to have a category pull down for "Region specific" scan codes, and label the scan codes descriptively based on the region selected.

Guess this is an overkill at this point.

[luteijn]

I spend a lot of time typing things on unix-like command lines through a terminal emulator. F13-F24 are special in that you should already be able to type them on normal PC keyboards with shift F1-F12, and that usually terminal emulators have a way to communicate them to the other side using escape sequences (although there are some things to keep in mind, see e.g. http://aperiodic.net/phil/archives/Geekery/term-function-keys.html - typically I'll have gnu screen running on the remote side). So most of these F keys can be used as keys that register on the remote side and trigger stuff there, it would be a shame to waste them on local customizations.

Also, popular window managers and the linux console use a lot the F-keys already by default. It would be nice to have these exotic codes to be able to send keys less likely to already be used by something locally.

[mondalaci]

I've added generic names as suggested. #821 also made me realize that generic names are the way to go.

Region specific scancodes are out of question because there's a 1:1 mapping between scancodes and names, and Agent operates on the USB level. Region specific handling happens at the OS level.

I don't want to add additional scancodes until their use is more justified.

[luteijn]

http://www.quadibloc.com/comp/scan.htm has some more information on scan-code use on more or less standard keyboards with more than the 104/105 keys most people are used to. As usual, the focus is on ps/2 and similar dedicated connections, but USB is mentioned too (find in page is your friend), and there is a section on international keys.