Shuduo Sang <shuduo.sang@xxxxxxxxxxxxx> 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@xxxxxxxxx> > 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@xxxxxxxxxxxxx> > Signed-off-by: Shuduo Sang <shuduo.sang@xxxxxxxxxxxxx> > --- > 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, ¤t_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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
