Bug 204743

I discussed this a bit with RussianNeuroMancer by email, let me copy and paste the relevant bits here, my first reply was:

###

Interesting I did not know HP had models with privacy screens too. As for the key, you need to add a mapping to the hp_wmi_keymap in drivers/platform/x86/hp-wmi.c for it. The key should be mapped to KEY_PRIVACY_SCREEN_TOGGLE . Note this key-code is somewhat new so evemu-record might show the keypresses like this:

E: 0.000001 0004 0004 0076    # EV_MSC / MSC_SCAN             76
E: 0.000001 0001 0279 0001    # EV_KEY / (null)               1
E: 0.000001 0000 0000 0000    # ------------ SYN_REPORT (0) ---------- +0ms
E: 0.003785 0004 0004 0076    # EV_MSC / MSC_SCAN             76
E: 0.003785 0001 0279 0000    # EV_KEY / (null)               0
E: 0.003785 0000 0000 0000    # ------------ SYN_REPORT (0) ---------- +3ms

This is fine, note the 0279 in the hexdump, that comes from:

#define KEY_PRIVACY_SCREEN_TOGGLE       0x279

###

Then after a closer look I realized that things were not that simple and I wrote:

###
So it seems I was wrong and this is not as simple as just adding a mapping to hp_wmi_keymap.

The "hp_wmi: Unknown event_id - 20 - 0x1" message prints 2 things: The first number is the event_id, the second number is event_data. This message is printed from a switch-case like this:

        switch (event_id) {
        case HPWMI_DOCK_EVENT:
		...
        default:
                pr_info("Unknown event_id - %d - 0x%x\n", event_id, event_data);
                break;
        }

And the hp_wmi_keymap is only used for event_id HPWMI_BEZEL_BUTTON (4)

       case HPWMI_BEZEL_BUTTON:
                key_code = hp_wmi_read_int(HPWMI_HOTKEY_QUERY);
                if (key_code < 0)
                        break;

                if (!sparse_keymap_report_event(hp_wmi_input_dev,
                                                key_code, 1, true))
                        pr_info("Unknown key code - 0x%x\n", key_code);
                break;



So this is not a case of just a missing keymap entry, this is a whole new type of event-id. So I guess that the new event-id of 20 (decimal) is related to the new privacy-screen stuff. It probably gets fired whenever the privacy screen is toggled on/off and the actual toggling is handled in firmware. And for some reason the even gets fired off on models without the privacy screen too.

So for now it would be best to just not do anything with this until we know how the actual privacy-screen support on HP is supposed to work. Once that is hooked up, then we can hopefully detect when there is no privacy-screen and re-purpose the button on those models. But I don't want to do that until we have things working on models which actually do have a privacy-screen.