[Mactel-linux-devel] MacBook (C2D) Japanese Keyboard problem

[Osamu A. <os...@de...>]

Hi,

I am trying to trace kernel USB keyboard issue and will appreciate help
to trace it down.

Problem: 
Few dead keys on APPLE_GEYSER4_JIS USB keyboard on MacBook.

Situation:
(Pathless filenames refer to the files in devices/usb/input/.)

As I see hid-core.c defines 3 types of keybord for each generation of
apple laptop PCs ANSI, ISO, JIS.
----
#define USB_DEVICE_ID_APPLE_GEYSER_ANSI 0x0214
#define USB_DEVICE_ID_APPLE_GEYSER_ISO  0x0215
#define USB_DEVICE_ID_APPLE_GEYSER_JIS  0x0216
#define USB_DEVICE_ID_APPLE_GEYSER3_ANSI x0217
#define USB_DEVICE_ID_APPLE_GEYSER3_ISO x0218
#define USB_DEVICE_ID_APPLE_GEYSER3_JIS x0219
#define USB_DEVICE_ID_APPLE_GEYSER4_ANSI x021A
#define USB_DEVICE_ID_APPLE_GEYSER4_ISO x021B
#define USB_DEVICE_ID_APPLE_GEYSER4_JIS x021C
----
These are model names and:
 ANSI is the 101 key sequence variant for USA.
 ISO  is the 102 key sequence variant for Europe.
 JSI  is the 106 key sequence variant for Japan.
I have x021C model (MacBook JP) here.

The key sequence difference between ANSI and ISO is taken care by
conditional (hid->quirks & HID_QUIRK_POWERBOOK_ISO_KEYBOARD) in
hid-input.c which swaps KEY_GRAVE and KEY_102ND using table
powerbook_iso_keyboard.

But I see no code for JIS.  Naturally I am suffering problem on my
MacBook(JP model) and need help to track down method to address this
problem.  I see no response with xev or showkey program.

Dead response keys are marked as following and cause following 8 byte
data to be passed to the kernel routines:

  MARKS               : _____U8_DATA__(HEX)____  TBL-> KEYCODE
  Yen-mark and bar    : 00 00 89 00 00 00 00 00   124  KEY_YEN
  Japanese RO         : 00 00 87 00 00 00 00 00    89  KEY_RO
  EISUU               : 00 00 91 00 00 00 00 00   123  KEY_HANGUL
  HIRAGANA/KATAKANA   : 00 00 89 00 00 00 00 00   122  KEY_HANJA

All other normal keys emmit real scan code in the 3rd BYTE and the talbe 
  static const unsigned char hid_keyboard[256] in hid-input.c converts
them to the Linux keycode (the one used by loadkeys and xmodmap) .
Funny thing is hid_keyboard table in source is valid for JIS but it does
not emmit keycode to user space.

I captured above 8 byte data sequence of key event by enabling DEBUG out
put in hid_input_report of hid-core.c.  This is the 8 byte data 
    u8 *data = urb->transfer_buffer

Funny thing is this key data will not come to the routine to convert
from hardware specific scan code to the Linux keycode using hid_keyboard
table
  static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_field *field, struct hid_usage *usage)
in hid-input.c.  So of course these are not passed to user space. 

I am not quite sure how these data evaporates in the kernel.  I see no
particular code to prevents them. 

Linux HID code get them so it is not hardware initialization issue and
these key responses are drop in the kernel code and must be fixed there.

Osamu