Comment 4 for bug 702407

On Fri, Jan 14, 2011 at 06:30:12PM -0000, Martin Pitt wrote:
> > thinkpad_acpi does send scancodes, but only when it's reporting
> KEY_UNKNOWN
>
> Ah, that would be part of the problem. In the reported cases, the faulty
> keys didn't have an unknown, but a wrong key code assigned.

Right, keymap just keeps the scan code in a static variable, so if the
driver doesn't send a scan code you just get whatever the last reported
scan code was.

> To be honest I'm not quite sure what you mean by the ordering issue.
> From what I understand, the input_event struct has both the scan and the
> key code, and there's one event sent with both? But even if there are
> two separate events for this, keymap -i just prints any incoming EV_KEY
> event, it doesn't discard any of them.

No, it's one event for the scan code (type = EV_MSC, code = MSC_SCAN,
value = scan code) and another for the key code (type = EV_KEY, code =
key code, value = state), and then a third that's a sync event (type =
EV_SYN, code = SYN_REPORT). The usual sequence is EV_MSC, EV_KEY,
EV_SYN, but thinkpad_acpi does either EV_KEY, EV_SYN or EV_KEY, EV_MSC,
EV_SYN, which are both problematic for keymap.

I'm getting ready to test a patch for thinkpad_acpi that will always
send the scan code, which I'll send upstream once I've verified it
works. This is what you need for the FN_F8 case you mentioned. It also
reorders the events to be consistent with what all the other drivers are
doing, so the current keymap should work properly.

I also hacked up a change to keymap that prints on the sync event
instead of the key event. Now I get output more like:

scan code: none key code: prog1
scan code: 0x1A key code: unknown
scan code: none key code: fn_f11
scan code: none key code: f24

I need to verify that drivers always send a sync event though; if not
keymap needs to print and reset the state for key events without
sync events in between.