Re: [RFC PATCH] support Thinkpad X1 Carbon's adaptive keyboard

Bjørn Mork
2014-03-03T11:04:05Z

Shuduo Sang <shuduo.sang@canonical.com> writes:

> Hi all,
>
> We are working together with Lenovo to enable thinkpad X1 Carbon's
> fancy feature, Adaptive Keyboard[1] for Linux. Adaptive keyboard has
> five modes on Windows including Home mode, Web browser mode, Web
> conference mode, Function mode and Lay-flat mode. We enabled Home
> mode and Function mode currently. Will try to find out how to enable
> other modes later. Please review and comment attached patch.
>
> Thanks,
> Shuduo
>
> [1]:http://shop.lenovo.com/us/en/laptops/thinkpad/x-series/x1-carbon/#features
>
>
> From da9d43beaa23071558a8031950cc21cc93946ec6 Mon Sep 17 00:00:00 2001
> From: Shuduo Sang <sangshuduo@gmail.com>
> Date: Mon, 3 Mar 2014 14:29:32 +0800
> Subject: [PATCH] support thinkpad X1 Carbon's adaptive keyboard
>
> Thinkpad X1 Carbon's adaptive keyboard has five modes including Home
> mode, Web browser mode, Web conference mode, Function mode and Lay-flat
> mode. We support Home mode and Function mode currently.
>
> Signed-off-by: Bruce Ma <bruce.ma@canonical.com>
> Signed-off-by: Shuduo Sang <shuduo.sang@canonical.com>
> ---
> drivers/platform/x86/thinkpad_acpi.c | 97
> ++++++++++++++++++++++++++++++++++++
> 1 file changed, 97 insertions(+)
>
> diff --git a/drivers/platform/x86/thinkpad_acpi.c
> b/drivers/platform/x86/thinkpad_acpi.c
> index defb6af..fcb738e 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -3437,6 +3437,101 @@ err_exit:
> return (res < 0)? res : 1;
> }
>
> +/* Thinkpad X1 Carbon support 5 modes including Home mode, Web browser
> + * mode, Web conference mode, Function mode and Lay-flat mode.
> + * We support Home mode and Function mode currently.
> + *
> + * Will consider support rest of modes in future.
> + *
> + */
> +enum ADAPTIVE_KEY_MODE {
> + HOME_MODE,
> + WEB_BROWSER_MODE,
> + WEB_CONFERENCE_MODE,
> + FUNCTION_MODE,
> + LAYFLAT_MODE
> +};
> +
> +int adaptive_keyboard_modes[] = {
> + HOME_MODE,
> +/* WEB_BROWSER_MODE = 2,
> + WEB_CONFERENCE_MODE = 3, */
> + FUNCTION_MODE
> +};
> +
> +#define DFR_CHANGE_ROW 0x101
> +#define DFR_SHOW_QUICKVIEW_ROW 0x102
> +
> +/* press Fn key a while second, it will switch to Function Mode. Then
> + * release Fn key, previous mode be restored.
> + */
> +bool adaptive_keyboard_mode_is_saved;
> +int adaptive_keybarod_prev_mode;

speling: s/keybarod/keyboard/

You need to change it where this variable is used below as well.

> +static int adaptive_keyboard_get_next_mode(int mode)
> +{
> + int i;
> + int max_mode = sizeof(adaptive_keyboard_modes)/sizeof(int) - 1;

ARRAY_SIZE

> + for (i = 0; i <= max_mode; i++) {
> + if (adaptive_keyboard_modes[i] == mode)
> + break;
> + }
> +
> + if (i >= max_mode)
> + i = 0;
> + else
> + i++;
> +
> + return adaptive_keyboard_modes[i];
> +}
> +
> +static bool adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
> +{
> + u32 current_mode = 0;
> + int new_mode = 0;
> +
> + switch (scancode) {
> + case DFR_CHANGE_ROW:
> + if (adaptive_keyboard_mode_is_saved) {
> + new_mode = adaptive_keybarod_prev_mode;
> + adaptive_keyboard_mode_is_saved = false;
> + } else {
> + if (!acpi_evalf(
> + hkey_handle, &current_mode,
> + "GTRW", "dd", 0)) {
> + pr_err("Cannot read adaptive keyboard mode\n");
> + return false;

Not sure about this return value (resulting in an "unhandled HKEY event"
message). See below.

> + } else {
> + new_mode = adaptive_keyboard_get_next_mode(
> + current_mode);
> + }
> + }
> +
> + if (!acpi_evalf(hkey_handle, NULL, "STRW", "vd", new_mode))
> + pr_err("Cannot set adaptive keyboard mode\n");
> +
> + return true;
> +
> + case DFR_SHOW_QUICKVIEW_ROW:
> + if (!acpi_evalf(hkey_handle,
> + &adaptive_keybarod_prev_mode,
> + "GTRW", "dd", 0)) {
> + pr_err("Cannot read adaptive keyboard mode\n");

You should at least return a consistent result for this error. Either
return true above or false here.

> + } else {
> + adaptive_keyboard_mode_is_saved = true;
> +
> + if (!acpi_evalf(hkey_handle,
> + NULL, "STRW", "vd", FUNCTION_MODE))
> + pr_err("Cannot set adaptive keyboard mode\n");
> + }
> + return true;
> +
> + default:
> + return false;
> + }
> +}
> +
> static bool hotkey_notify_hotkey(const u32 hkey,
> bool *send_acpi_ev,
> bool *ignore_acpi_ev)
> @@ -3456,6 +3551,8 @@ static bool hotkey_notify_hotkey(const u32 hkey,
> *ignore_acpi_ev = true;
> }
> return true;
> + } else {
> + return adaptive_keyboard_hotkey_notify_hotkey(scancode);
> }
> return false;

This isn't reached anymore...

> }

I also think you should consider how this UI will look if you ever
decide to enable all the modes. AFAICS, you will then have inconsistent
behaviour for the DFR_CHANGE_ROW scancode in FUNCTION_MODE:

a) if FUNCTION_MODE was enabled by DFR_SHOW_QUICKVIEW_ROW then next
mode is x, where x can be any mode active before the
DFR_SHOW_QUICKVIEW_ROW event _including_ FUNCTION_MODE
b) if FUNCTION_MODE was enabled by DFR_CHANGE_ROW then next
mode is LAYFLAT_MODE

So the user won't really know the effect of a DFR_CHANGE_ROW event in
FUNCTION_MODE.

Wouldn't it make more sense if DFR_SHOW_QUICKVIEW_ROW always toggled
between FUNCTION_MODE and some other mode, and DFR_CHANGE_ROW always
cycled through the modes?

Or is the UI locked by whatever the Windows driver does? (I don't have
any X1 Carbon, so I don't know how the users expect this to work)

Bjørn