Can't use KC_LANG1 & KC_LANG2 key

[vvakame]

Hi, I'm enjoying ErgoDox EZ!

I want to use KC_LANG1 & KC_LANG2 Key that is important feature for japanese user.
KC_LANG1 is switch to english input mode and KC_LANG2 is switch to japanese input mode key.
Here is my keymap.c https://github.com/vvakame/qmk_firmware/blob/0e1bb350ab3efc1473b25e256bc648fda0ab2074/keyboard/ergodox_ez/keymaps/vv/keymap.c#L15-L55

I tried CONSOLE_ENABLE=yes and hid_listen.
I added debug log to action_for_key function (keymap_common.c). I got KC_LANG1 response from keyboard. but It was not possible to exhibit the effect. 😿

KC_LANG1&2 is works fine from massdrop settings. https://keyboard-configurator.massdrop.com/ext/ergodox/?referer=XEG9GJ&hash=7c963a9ba9dad9108e4dc854c22aaecd
But qmk_firmware is not.

I'm happy if I get any advice.

[ezuk]

@jackhumbert any thoughts on this one?

[jackhumbert]

Here are some japanese-specific keycodes from keycode.h - do they do anything for you?

/* Japanese specific */
#define KC_ZKHK KC_GRAVE
#define KC_RO   KC_INT1
#define KC_KANA KC_INT2
#define KC_JYEN KC_INT3
#define KC_JPY  KC_INT3
#define KC_HENK KC_INT4
#define KC_MHEN KC_INT5

[vvakame]

thank you for advice.
but it is not what I'm looking for..
I think there key is uses for Windows. (I am Mac OS X user)
I'll investigation little by little.

---

from http://www.usb.org/developers/hidpage/Hut1_12v2.pdf
10 Keyboard/Keypad Page (0x07) and Footnotes 15-20

maybe KC_ZKHK(0x35) means ZenKaku/HanKaku(全角/半角)(Fullwidth/Halfwidth char) input mode toggle key.
http://www.unicode.org/reports/tr11/tr11-15.html

KC_RO(0x87) means switch to input by Romaji(ローマ字) mode.
KC_KANA(0x88) means switch to input by Kana(かな) mode.
https://en.wikipedia.org/wiki/Romanization_of_Japanese

KC_JYEN&KC_JPY(0x88) means Japanese Yen(¥ mark) character.

KC_HENK(0x89) means henkan(変換)(convert) key.
KC_MHEN(0x8A) means mu-henkan(無変換)(no convert) key.

and...
http://www2d.biglobe.ne.jp/~msyk/keyboard/layout/usbkeycode.html
from site write.

Apple Pro Keyboard (JIS-align)
英数 key (switch to english input mode) == Keyboard LANG2 in Usage Name (HID Usage Tables 1.11)
かな カナ key (switch to japanese input mode) == Keyboard LANG1 in Usage Name (HID Usage Tables 1.11)

one more.
I read massdrop generated source code.
and they code use KEY_LANG1(0x90) and KEY_LANG2(0x91). (maybe...)

[jackhumbert]

Yeah, it looks like the Massdrop configurator uses 0x90/0x91, so KC_LANG1 and KC_LANG2 should be doing the exact same thing :/ you mentioned that you got a response from these when you used them in QMK - what exactly happened?

This might be a device/vendor ID issue - OS X can be kind of picky about that. It looks like the configurator uses these IDs:

#define VENDOR_ID       0x1d50  // Openmoko, Inc.
#define PRODUCT_ID      0x6028  // ErgoDox ergonomic keyboard

You can modify these in QMK by editing your config.h file.

[vvakame]

what exactly happened?

I modified this line.
https://github.com/vvakame/qmk_firmware/blob/254503cedab9830cfc192a47d16ed599d6c20e4f/quantum/keymap_common.c#L49-L51

modified code.

    uint16_t keycode = keymap_key_to_keycode(layer, key);

    print("in action_for_key: ");
    phex(keycode);
    print("\n");

    switch (keycode) {

and exec command & get response.

$ ./hid_listen.mac
Waiting for device:.............
Listening:
boogmagic scan: ... done.
Keyboard start.
in action_for_key: 04     # press a key
in action_for_key: 04
in action_for_key: 04
in action_for_key: 1D     # press z key
in action_for_key: 1D
in action_for_key: 1D
in action_for_key: 90     # press KC_LANG1 key
in action_for_key: 90
in action_for_key: 90
in action_for_key: 91     # oress KC_LANG2 key
in action_for_key: 91
in action_for_key: 91

But IME(Input Method Editor) can't get affected.

is this answer intended?

---

You can modify these in QMK by editing your config.h file.

I tried to modify keyboard/ergodox_ez/config.h.

$ system_profiler SPUSBDataType USB
USB:

    USB 3.0 Bus:

      Host Controller Driver: AppleUSBXHCILPTH
      PCI Device ID: 0x8c31
      PCI Revision ID: 0x0005
      PCI Vendor ID: 0x8086

...omit...

        ErgoDox EZ:

          Product ID: 0x6028
          Vendor ID: 0x1d50
          Version: 0.01
          Speed: Up to 12 Mb/sec
          Manufacturer: ErgoDox EZ
          Location ID: 0x14200000 / 23
          Current Available (mA): 1000
          Current Required (mA): 500
          Extra Operating Current (mA): 0

but I can't get expected result...

[ezuk]

@eltang - thank you for your willingness to help, and for wanting to participate!

Before asking question such as this, I ask that you please take the time to fix your own keymap. I'd love to see you apply your considerable expertise to your own issue before helping others, so that you are able to test changes. This is a basic requirement for supporting others -- being able to compile and flash keymaps on your own hardware, so you can evaluate your own suggestions rather than making guesses.

The steps you should follow are clearly outlined here. Please don't hesitate to ask me there if there is anything that you find too difficult or confusing.

For now, I have removed your comment, and will remove similar comments until you are able to find the time to correct your own technical problems. Thanks again!

@vvakame - my apologies. Please don't feel that you need to reply to Eric's vague question, which I have now removed. I will let @jackhumbert take it from here.

[vvakame]

Hi! I got answer this issue.
but I don't understand why I can solve this issue.
I'll write a report later. please wait.

[vvakame]

@ezuk @jackhumbert I made commit, it works fine. vvakame@719b866
I can't give explanation... I think maybe OS side driver matter.
I did't change VENDOR_ID and PRODUCT_ID finally.
I can send a pull request. Do you guys think this change is correct?

---

@mhidaka give support & some comment to me. thanks!

[jackhumbert]

Interesting - thanks for sharing! @abcminiuser uses a similarly lower value here (0x65 instead of 0x68 compared to the TMK default of 0xFF) for the keyboard demo in Lufa.

It looks like the 0x68 is used in the configurator's descriptors, which may indicate a 104-key keyboard (0x68 is 104), and 0x65 would be a 101-key one. It's possible that most OSes wouldn't know what to do with the 0xFF (255-key keyboard), which causes this trouble.

I wonder if this is also causing the Mac-related media key problems.

[jackhumbert]

Let me test this today, but it's looking good, so if you'd like to create a pull request, that would be awesome :)

[vvakame]

yay! 👍

I wonder if this is also causing the Mac-related media key problems.

My ErgoDox EZ works fine about KC_MPLY, KC_MNXT, KC_MPRV, KC_VOLU, KC_VOLD, KC_MUTE.

I'll send a pull request. 😉
I'm making & setup Windows environment. please wait.

[vvakame]

Bad news..

in Windows 10 (Surface Pro 4).
KC_ZKHK is works fine with 0x65 and 0x68.
but KC_RO, KC_KANA, KC_JYEN, KC_JPY, KC_HENK, KC_MHEN is not working with 0x65 and 0x68.

I tried 0x6D but it is not working too. 109(0x6D) keyboard is main stream in Japan+Windows.
0xFF works perfect...

related? https://support.microsoft.com/en-us/kb/927824

[jackhumbert]

Ah, interesting. Do those japanese-specific keycodes work in OS X with your changes?

[vvakame]

Yes!

summary.

in Mac OS X
KC_LANG1 and KC_LANG2 is works fine with 0x65, 0x68 and 0x6D. but 0xFF is not working.
MacBook built-in keyboard does not have KC_ZKHK, KC_RO, KC_KANA, KC_JYEN, KC_JPY, KC_HENK, KC_MHEN key.
vvakame@719b866 works that I expected.

in Windows
KC_ZKHK, KC_RO, KC_KANA, KC_JYEN, KC_JPY, KC_HENK, KC_MHEN is works fine with 0xFF. but 0x68, 0x6D is not working.
109 keyboard does not have KC_LANG1, KC_LANG2.
https://github.com/jackhumbert/qmk_firmware works that japanese user expected. (maybe I think so.)

---

0x89 is not working Mac and Windows both.

---

I go to bed. now is 3:00 am in japan.

[jackhumbert]

Awesome - I'll talk to @ezuk about working on documentation for that, since I'm not sure we wanna commit anything that varies from 0xFF.

Thanks for diving into this!

[zoetrope]

I tried in Ubuntu 16.04.
KC_ZKHK, KC_KANA, KC_JYEN, KC_HENK, KC_MHEN is works fine with 0xFF. but 0x68, 0x6D, 0x89 is not working.

[tmk]

Checked HID specification and found description like Logical Min/Max contains signed value. I guess 0xFF means -1, not 255 there and we have to use 16 bit value for Logical Maximum.

Can someone test this patch?

diff --git a/tmk_core/protocol/lufa/descriptor.c b/tmk_core/protocol/lufa/descriptor.c
index c13a81b..bcc4173 100644
--- a/tmk_core/protocol/lufa/descriptor.c
+++ b/tmk_core/protocol/lufa/descriptor.c
@@ -76,7 +76,7 @@ const USB_Descriptor_HIDReport_Datatype_t PROGMEM KeyboardReport[] =
         HID_RI_USAGE_MINIMUM(8, 0x00), /* Reserved (no event indicated) */
         HID_RI_USAGE_MAXIMUM(8, 0xFF), /* Keyboard Application */
         HID_RI_LOGICAL_MINIMUM(8, 0x00),
-        HID_RI_LOGICAL_MAXIMUM(8, 0xFF),
+        HID_RI_LOGICAL_MAXIMUM(16, 0x00FF),
         HID_RI_REPORT_COUNT(8, 0x06),
         HID_RI_REPORT_SIZE(8, 0x08),
         HID_RI_INPUT(8, HID_IOF_DATA | HID_IOF_ARRAY | HID_IOF_ABSOLUTE),

[vvakame]

I'll try your patch tonight! (please ping if I have forgotten...

[vvakame]

I tried it. It works fine in Max OS X!
I'll test on Windows, please wait in a day...

[vvakame]

It works fine in my Mac OS X and Windows 10 environment! 👍