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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Mactel-linux-devel mailing list
Mactel-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mactel-linux-devel
