Four keys do not work on Japanese keyboard model

[sibradzic]

On MacBook9,1 here (Macbook 12" JIS, Model A1534 EMC 2991, Early 2016), and at least four keys do not work at all, showkey can't scan any input when these are pressed:

• (¥ / |), yen / pipe, located between tilde and delete keys
• (ろ / _), ro / underline, located between slash and shift keys
• (英数), eisu, located between left command and space keys
• (かな), kana, located between space and right command keys

I've tried inserting some key codes into applespi_scancodes[], ones that I've scooped from Linux kernel input headers that should match those Japanese keys, but the keys remained dead :| I suspect some special Apple JIS-related quirk may be needed for this, such as https://github.com/torvalds/linux/blob/master/drivers/hid/hid-apple.c#L298, as Japanese keyboards have more keys the the others and Apple really does not make things simple.

The lack of pipe & underline keys is especially bothersome, can't do anything feasible in shell... I'm more than willing to test some patches, if you please :)

[sibradzic]

Oh, and by the way, thanks for the excellent driver, awesome work!

[roadrunner2]

@sibradzic Can you print out the raw scancodes when you press those keys? E.g. add something like the following near the top of applespi_code_to_key(...):

    pr_info("scancode: %u\n", code);

And report what codes are printed when you press those keys (if your dmesg supports -w, I recommend running dmesg -w | grep scancode in a separate terminal to immediately see what code is reported for a key).

[sibradzic]

@roadrunner2 I can try. Before I saw your comment I've enabled DEBUG_ALL_READ, and here is what applespi->rx_buffer shows when pressing those keys:

underline: 0x87 135
20 01 00 00 00 00 14 00 10 01 00 7e 00 00 0a 00 01 00 00 87 00 00 00 00 00 00 15 a0 00 00 00 00
 (zeroes)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 df

pipe: 0x89 137
20 01 00 00 00 00 14 00 10 01 00 7c 00 00 0a 00 01 00 00 89 00 00 00 00 00 00 78 61 00 00 00 00
 (zeroes)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 df

kana: 0x90 144
20 01 00 00 00 00 14 00 10 01 00 82 00 00 0a 00 01 00 00 90 00 00 00 00 00 00 8e e0 00 00 00 00
 (zeroes)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 df

eisu: 0x91 145
20 01 00 00 00 00 14 00 10 01 00 80 00 00 0a 00 01 00 00 91 00 00 00 00 00 00 1c 21 00 00 00 00
 (zeroes)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 df

So, I guess the codes are, in decimal, 135, 137, 144 & 145

[sibradzic]

Yep, same thing I get with pr_info("scancode: %u\n", code);;

kernel: [ 2316.822686] applespi: scancode: 135
kernel: [ 2317.178456] applespi: scancode: 137
kernel: [ 2319.798709] applespi: scancode: 144
kernel: [ 2320.198482] applespi: scancode: 145

So, how does one add this into applespi_scancodes[]?

[sibradzic]

Hmmm, I figured it out, one need to grow the applespi_scancodes to fit the 145 codes :|

[roadrunner2]

@sibradzic Exactly! The current array is only set up for scancodes 0 - 101, so it need to be extended.

Besides these 4 missing keys, are any others wrong?

[sibradzic]

@roadrunner2, thanks for the hints, I think all the keys @ JIS layout are covered now. #35 fixes it.

[Dunedan]

Great job @sibradzic :+1: I'm curious what the scancodes in between keys are. I mean it's pretty obvious that they correspond to keys on other keyboard layouts, but will we ever figure out which ones?

[Dunedan]

Oh and btw: I guess the keys in question are somewhere hidden in plain sight on the following page: https://support.apple.com/en-us/HT201794 ;-)

[sibradzic]

@Dunedan I'm don't think we can do too much without someone confirming the key codes for all these layouts. I've dig through kernel code looking for a "generic" Apple keyboard key-code-to-event-code mapping data-structures, such as one in https://github.com/torvalds/linux/blob/master/drivers/macintosh/adbhid.c#L78. That particular mapping is for PowerPC Mac keyboards, and it is not even close to a mapping we have in this driver. If someone has more insight into the situation, the help would be more than welcome...

@roadrunner2 @cb22 maybe we should add pr_debug("scancode: %u\n", code); in the applespi_code_to_key(...), to enable people to scan for those codes without re-compiling the driver?

[roadrunner2]

@sibradzic I was just thinking the same thing.

[cb22]

@sibradzic @roadrunner2 agreed.