[GIT PULL] thinkpad-acpi queue for 2.6.23 (v2)

[GIT PULL] thinkpad-acpi queue for 2.6.23 (v2)

[Henrique de Moraes Holschuh]

Len,

Please pull from:                                                                                                                                     
git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git for-upstream/acpi-test                                                                     

to receive the first batch of thinkpad-acpi changes for 2.6.23, now rebased to
apply on top of v2.6.22:

      ACPI: thinkpad-acpi: add DMI-based modalias
      ACPI: thinkpad-acpi: remove all uneeded initializers
      ACPI: thinkpad-acpi: update information on T43 thermal sensor 0xc1
      ACPI: thinkpad-acpi: enable more hotkeys
      ACPI: thinkpad-acpi: export hotkey maximum masks
      ACPI: thinkpad-acpi: export to sysfs the state of the radio slider switch
      ACPI: thinkpad-acpi: checkpoint sysfs interface version due to hotkey
      ACPI: thinkpad-acpi: update CMOS commands documentation
      ACPI: thinkpad-acpi: register input device
      ACPI: thinkpad-acpi: add input device support to hotkey subdriver
      ACPI: thinkpad-acpi: make the input event mode the default
      ACPI: thinkpad-acpi: add power-management handler capability
      ACPI: thinkpad-acpi: export EV_SW SW_RADIO events
      ACPI: thinkpad-acpi: checkpoint sysfs interface version due to input layer
      ACPI: thinkpad-acpi: rename pci HID constant

And to also receive the second batch of thinkpad-acpi changes for 2.6.23:

      ACPI: thinkpad_acpi: use bool for boolean parameters
      pci-ids: add Lenovo PCI vendor ID
      ACPI: thinkpad-acpi: store ThinkPad model information
      ACPI: thinkpad-acpi: allow use of CMOS NVRAM for brightness control
      ACPI: thinkpad-acpi: react to Lenovo ThinkPad differences in hot key
      ACPI: thinkpad-acpi: make sure DSDT TMPx readings don't return +128
      ACPI: thinkpad-acpi: make EC-based thermal readings non-experimental
      ACPI: thinkpad-acpi: bump up version to 0.15


These changes are composed mainly of the first part of the effort to move all
the hot keys functionality to the input layer, plus some fixes.

All these patches are targetted to 2.6.23.  Please merge for acpi-test.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: enable more hotkeys

[Henrique de Moraes Holschuh]

Revise ACPI HKEY functionality to better interface with the firmware, and
enable up to 32 regular hotkeys, instead of just 16 of them.  Ouch.

This takes care of most keys one used to have to do CMOS NVRAM polling on,
and should drop the need for tpb, thinkpad-keys, and other such 5Hz NVRAM
polling power vampires on most modern ThinkPads ;-)

And, just to add insult to injury, this was sort of working since forever
through the procfs interface, but nobody noticed or tried an echo
0xffffffff > /proc/acpi/ibm/hotkey and told me it would generate weird
events. ARGH!

Thanks to Richard Hughes for kicking off the work that ended up with this
discovery, and to Matthew Garret for calling my attention to the fact that
newer ThinkPads were indeed generating ACPI GPEs when such hot keys were
pressed.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Richard Hughes <hughsient@gmail.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
---
 Documentation/thinkpad-acpi.txt |   41 ++++++++++++++++----------------------
 drivers/misc/thinkpad_acpi.c    |   38 ++++++++++++++++++++---------------
 drivers/misc/thinkpad_acpi.h    |    6 ++--
 3 files changed, 42 insertions(+), 43 deletions(-)

diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index b90d9a7..2f30db0 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -153,29 +153,22 @@ addition, the lid microswitch and some docking station buttons may
 also generate such events.
 
 The bit mask allows some control over which hot keys generate ACPI
-events. Not all bits in the mask can be modified. Not all bits that
-can be modified do anything. Not all hot keys can be individually
-controlled by the mask. Most recent ThinkPad models honor the
-following bits (assuming the hot keys feature has been enabled):
-
-	key	bit	behavior when set	behavior when unset
-
-	Fn-F3			always generates ACPI event
-	Fn-F4			always generates ACPI event
-	Fn-F5	0010	generate ACPI event	enable/disable Bluetooth
-	Fn-F7	0040	generate ACPI event	switch LCD and external display
-	Fn-F8	0080	generate ACPI event	expand screen or none
-	Fn-F9	0100	generate ACPI event	none
-	Fn-F12			always generates ACPI event
-
-Some models do not support all of the above. For example, the T30 does
-not support Fn-F5 and Fn-F9. Other models do not support the mask at
-all. On those models, hot keys cannot be controlled individually.
+events. Not all bits in the mask can be modified. Not all bits that can
+be modified do anything. Not all hot keys can be individually controlled
+by the mask. Some models do not support the mask at all. On those
+models, hot keys cannot be controlled individually.
 
 Note that enabling ACPI events for some keys prevents their default
-behavior. For example, if events for Fn-F5 are enabled, that key will
-no longer enable/disable Bluetooth by itself. This can still be done
-from an acpid handler for the ibm/hotkey event.
+behavior. For example, if events for Fn-F5 are enabled, that key will no
+longer enable/disable Bluetooth by itself. This can still be done from
+an acpid handler for the ibm/hotkey event.
+
+On some models, even enabling/disabling the entire hot key feature may
+change the way some keys behave (e.g. in a T43, Fn+F4 will generate an
+button/sleep ACPI event if hot keys are disabled, and it will ignore its
+mask when hot keys are enabled, so the key always does something.  On a
+X40, Fn+F4 respects its mask status, but generates the button/sleep ACPI
+event if masked off).
 
 Note also that not all Fn key combinations are supported through
 ACPI. For example, on the X40, the brightness, volume and "Access IBM"
@@ -189,9 +182,9 @@ The following commands can be written to the /proc/acpi/ibm/hotkey file:
 
 	echo enable > /proc/acpi/ibm/hotkey -- enable the hot keys feature
 	echo disable > /proc/acpi/ibm/hotkey -- disable the hot keys feature
-	echo 0xffff > /proc/acpi/ibm/hotkey -- enable all possible hot keys
-	echo 0x0000 > /proc/acpi/ibm/hotkey -- disable all possible hot keys
-	... any other 4-hex-digit mask ...
+	echo 0xffffffff > /proc/acpi/ibm/hotkey -- enable all hot keys
+	echo 0 > /proc/acpi/ibm/hotkey -- disable all possible hot keys
+	... any other 8-hex-digit mask ...
 	echo reset > /proc/acpi/ibm/hotkey -- restore the original mask
 
 sysfs notes:
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 9f10b46..450b1e5 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -727,7 +727,7 @@ static struct ibm_struct thinkpad_acpi_driver_data = {
  */
 
 static int hotkey_orig_status;
-static int hotkey_orig_mask;
+static u32 hotkey_orig_mask;
 
 static struct attribute_set *hotkey_dev_attributes;
 
@@ -736,7 +736,8 @@ static ssize_t hotkey_enable_show(struct device *dev,
 			   struct device_attribute *attr,
 			   char *buf)
 {
-	int res, status, mask;
+	int res, status;
+	u32 mask;
 
 	res = hotkey_get(&status, &mask);
 	if (res)
@@ -750,7 +751,8 @@ static ssize_t hotkey_enable_store(struct device *dev,
 			    const char *buf, size_t count)
 {
 	unsigned long t;
-	int res, status, mask;
+	int res, status;
+	u32 mask;
 
 	if (parse_strtoul(buf, 1, &t))
 		return -EINVAL;
@@ -771,13 +773,14 @@ static ssize_t hotkey_mask_show(struct device *dev,
 			   struct device_attribute *attr,
 			   char *buf)
 {
-	int res, status, mask;
+	int res, status;
+	u32 mask;
 
 	res = hotkey_get(&status, &mask);
 	if (res)
 		return res;
 
-	return snprintf(buf, PAGE_SIZE, "0x%04x\n", mask);
+	return snprintf(buf, PAGE_SIZE, "0x%08x\n", mask);
 }
 
 static ssize_t hotkey_mask_store(struct device *dev,
@@ -785,9 +788,10 @@ static ssize_t hotkey_mask_store(struct device *dev,
 			    const char *buf, size_t count)
 {
 	unsigned long t;
-	int res, status, mask;
+	int res, status;
+	u32 mask;
 
-	if (parse_strtoul(buf, 0xffff, &t))
+	if (parse_strtoul(buf, 0xffffffffUL, &t))
 		return -EINVAL;
 
 	res = hotkey_get(&status, &mask);
@@ -817,7 +821,7 @@ static ssize_t hotkey_bios_mask_show(struct device *dev,
 			   struct device_attribute *attr,
 			   char *buf)
 {
-	return snprintf(buf, PAGE_SIZE, "0x%04x\n", hotkey_orig_mask);
+	return snprintf(buf, PAGE_SIZE, "0x%08x\n", hotkey_orig_mask);
 }
 
 static struct device_attribute dev_attr_hotkey_bios_mask =
@@ -902,10 +906,10 @@ static void hotkey_notify(struct ibm_struct *ibm, u32 event)
 {
 	int hkey;
 
-	if (acpi_evalf(hkey_handle, &hkey, "MHKP", "d"))
+	if (event == 0x80 && acpi_evalf(hkey_handle, &hkey, "MHKP", "d")) {
 		acpi_bus_generate_event(ibm->acpi->device, event, hkey);
-	else {
-		printk(IBM_ERR "unknown hotkey event %d\n", event);
+	} else {
+		printk(IBM_ERR "unknown hotkey notification event %d\n", event);
 		acpi_bus_generate_event(ibm->acpi->device, event, 0);
 	}
 }
@@ -913,7 +917,7 @@ static void hotkey_notify(struct ibm_struct *ibm, u32 event)
 /*
  * Call with hotkey_mutex held
  */
-static int hotkey_get(int *status, int *mask)
+static int hotkey_get(int *status, u32 *mask)
 {
 	if (!acpi_evalf(hkey_handle, status, "DHKC", "d"))
 		return -EIO;
@@ -928,7 +932,7 @@ static int hotkey_get(int *status, int *mask)
 /*
  * Call with hotkey_mutex held
  */
-static int hotkey_set(int status, int mask)
+static int hotkey_set(int status, u32 mask)
 {
 	int i;
 
@@ -949,7 +953,8 @@ static int hotkey_set(int status, int mask)
 /* procfs -------------------------------------------------------------- */
 static int hotkey_read(char *p)
 {
-	int res, status, mask;
+	int res, status;
+	u32 mask;
 	int len = 0;
 
 	if (!tp_features.hotkey) {
@@ -967,7 +972,7 @@ static int hotkey_read(char *p)
 
 	len += sprintf(p + len, "status:\t\t%s\n", enabled(status, 0));
 	if (tp_features.hotkey_mask) {
-		len += sprintf(p + len, "mask:\t\t0x%04x\n", mask);
+		len += sprintf(p + len, "mask:\t\t0x%08x\n", mask);
 		len += sprintf(p + len,
 			       "commands:\tenable, disable, reset, <mask>\n");
 	} else {
@@ -980,7 +985,8 @@ static int hotkey_read(char *p)
 
 static int hotkey_write(char *buf)
 {
-	int res, status, mask;
+	int res, status;
+	u32 mask;
 	char *cmd;
 	int do_cmd = 0;
 
diff --git a/drivers/misc/thinkpad_acpi.h b/drivers/misc/thinkpad_acpi.h
index 72d62f2..e1a64f0 100644
--- a/drivers/misc/thinkpad_acpi.h
+++ b/drivers/misc/thinkpad_acpi.h
@@ -415,14 +415,14 @@ static int fan_write_cmd_watchdog(const char *cmd, int *rc);
  */
 
 static int hotkey_orig_status;
-static int hotkey_orig_mask;
+static u32 hotkey_orig_mask;
 
 static struct mutex hotkey_mutex;
 
 static int hotkey_init(struct ibm_init_struct *iibm);
 static void hotkey_exit(void);
-static int hotkey_get(int *status, int *mask);
-static int hotkey_set(int status, int mask);
+static int hotkey_get(int *status, u32 *mask);
+static int hotkey_set(int status, u32 mask);
 static void hotkey_notify(struct ibm_struct *ibm, u32 event);
 static int hotkey_read(char *p);
 static int hotkey_write(char *buf);
-- 
1.5.2.1

ACPI: thinkpad-acpi: add DMI-based modalias

[Henrique de Moraes Holschuh]

Add DMI-based aliases to allow module autoloading on select thinkpads.

The aliases will do nothing unless the dmi-based-module-autoloading.patch
patch from Lennart Poettering <mzxreary-uLTowLwuiw4b1SvskN2V4Q@public.gmane.org> is applied.  Lennart's
patch has been accepted by greghk and will be merged eventually.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
Cc: Lennart Poettering <mzxreary-uLTowLwuiw4b1SvskN2V4Q@public.gmane.org>
---
 drivers/misc/thinkpad_acpi.c |   23 +++++++++++++++++++++++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 95c0b96..22a5f22 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -92,6 +92,29 @@ MODULE_LICENSE("GPL");
 /* Please remove this in year 2009 */
 MODULE_ALIAS("ibm_acpi");
 
+/*
+ * DMI matching for module autoloading
+ *
+ * See http://thinkwiki.org/wiki/List_of_DMI_IDs
+ * See http://thinkwiki.org/wiki/BIOS_Upgrade_Downloads
+ *
+ * Only models listed in thinkwiki will be supported, so add yours
+ * if it is not there yet.
+ */
+#define IBM_BIOS_MODULE_ALIAS(__type) \
+	MODULE_ALIAS("dmi:bvnIBM:bvr" __type "ET??WW")
+
+/* Non-ancient thinkpads */
+MODULE_ALIAS("dmi:bvnIBM:*:svnIBM:*:pvrThinkPad*:rvnIBM:*");
+MODULE_ALIAS("dmi:bvnLENOVO:*:svnLENOVO:*:pvrThinkPad*:rvnLENOVO:*");
+
+/* Ancient thinkpad BIOSes have to be identified by
+ * BIOS type or model number, and there are far less
+ * BIOS types than model numbers... */
+IBM_BIOS_MODULE_ALIAS("I[B,D,H,I,M,N,O,T,W,V,Y,Z]");
+IBM_BIOS_MODULE_ALIAS("1[0,3,6,8,A-G,I,K,M-P,S,T]");
+IBM_BIOS_MODULE_ALIAS("K[U,X-Z]");
+
 #define __unused __attribute__ ((unused))
 
 /****************************************************************************
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: remove all uneeded initializers

[Henrique de Moraes Holschuh]

Remove all initializers to NULL or zero.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
---
 drivers/misc/thinkpad_acpi.c |   16 ++++++++--------
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 22a5f22..9f10b46 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -129,7 +129,7 @@ IBM_BIOS_MODULE_ALIAS("K[U,X-Z]");
  * ACPI basic handles
  */
 
-static acpi_handle root_handle = NULL;
+static acpi_handle root_handle;
 
 #define IBM_HANDLE(object, parent, paths...)			\
 	static acpi_handle  object##_handle;			\
@@ -515,8 +515,8 @@ static char *next_cmd(char **cmds)
  ****************************************************************************
  ****************************************************************************/
 
-static struct platform_device *tpacpi_pdev = NULL;
-static struct class_device *tpacpi_hwmon = NULL;
+static struct platform_device *tpacpi_pdev;
+static struct class_device *tpacpi_hwmon;
 
 static struct platform_driver tpacpi_pdriver = {
 	.driver = {
@@ -729,7 +729,7 @@ static struct ibm_struct thinkpad_acpi_driver_data = {
 static int hotkey_orig_status;
 static int hotkey_orig_mask;
 
-static struct attribute_set *hotkey_dev_attributes = NULL;
+static struct attribute_set *hotkey_dev_attributes;
 
 /* sysfs hotkey enable ------------------------------------------------- */
 static ssize_t hotkey_enable_show(struct device *dev,
@@ -2694,7 +2694,7 @@ static struct ibm_struct ecdump_driver_data = {
  * Backlight/brightness subdriver
  */
 
-static struct backlight_device *ibm_backlight_device = NULL;
+static struct backlight_device *ibm_backlight_device;
 
 static struct backlight_ops ibm_backlight_data = {
         .get_brightness = brightness_get,
@@ -3497,7 +3497,7 @@ static void fan_watchdog_fire(struct work_struct *ignored)
 
 static void fan_watchdog_reset(void)
 {
-	static int fan_watchdog_active = 0;
+	static int fan_watchdog_active;
 
 	if (fan_control_access_mode == TPACPI_FAN_WR_NONE)
 		return;
@@ -3900,7 +3900,7 @@ static struct ibm_struct fan_driver_data = {
  ****************************************************************************/
 
 /* /proc support */
-static struct proc_dir_entry *proc_dir = NULL;
+static struct proc_dir_entry *proc_dir;
 
 /* Subdriver registry */
 static LIST_HEAD(tpacpi_all_drivers);
@@ -4043,7 +4043,7 @@ static void ibm_exit(struct ibm_struct *ibm)
 
 /* Probing */
 
-static char *ibm_thinkpad_ec_found = NULL;
+static char *ibm_thinkpad_ec_found;
 
 static char* __init check_dmi_for_ec(void)
 {
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: update information on T43 thermal sensor 0xc1

[Henrique de Moraes Holschuh]

Update the documentation with some extra data on the T43 thermal sensor
@0xc1, thanks to Alexey Fisher.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
---
 Documentation/thinkpad-acpi.txt |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index 9e6b94f..b90d9a7 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -562,7 +562,8 @@ http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p
 2:  System board, left side (near PCMCIA slot), reported as HDAPS temp
 3:  PCMCIA slot
 9:  MCH (northbridge) to DRAM Bus
-10: ICH (southbridge), under Mini-PCI card, under touchpad
+10: Clock-generator, mini-pci card and ICH (southbridge), under Mini-PCI
+    card, under touchpad
 11: Power regulator, underside of system board, below F2 key
 
 The A31 has a very atypical layout for the thermal sensors
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: export hotkey maximum masks

[Henrique de Moraes Holschuh]

The firmware knows how many hot keys it supports, so export this
information in a sysfs attribute.

And the driver knows which keys are always handled by the firmware in all
known ThinkPad models too, so export this information as well in a sysfs
attribute.  Unless you know which events need to be handled in a passive
way, do *not* enable hotkeys that are always handled by the firmware.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
---
 Documentation/thinkpad-acpi.txt |   13 +++++++++++++
 drivers/misc/thinkpad_acpi.c    |   37 ++++++++++++++++++++++++++++++++++++-
 2 files changed, 49 insertions(+), 1 deletions(-)

diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index 2f30db0..142a14f 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -214,6 +214,19 @@ sysfs notes:
 		key (see above).  Returns the current status of the hot
 		keys mask, and allows one to modify it.
 
+	hotkey_all_mask:
+		bit mask that should enable event reporting for all
+		supported hot keys, when echoed to hotkey_mask above.
+		Unless you know which events need to be handled
+		passively (because the firmware *will* handle them
+		anyway), do *not* use hotkey_all_mask.  Use
+		hotkey_recommended_mask, instead. You have been warned.
+
+	hotkey_recommended_mask:
+		bit mask that should enable event reporting for all
+		supported hot keys, except those which are handled by
+		the firmware.  Echo it to hotkey_mask above, to use.
+
 
 Bluetooth
 ---------
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 450b1e5..8c08868 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -728,6 +728,8 @@ static struct ibm_struct thinkpad_acpi_driver_data = {
 
 static int hotkey_orig_status;
 static u32 hotkey_orig_mask;
+static u32 hotkey_all_mask;
+static u32 hotkey_reserved_mask = 0x00778000;
 
 static struct attribute_set *hotkey_dev_attributes;
 
@@ -827,12 +829,38 @@ static ssize_t hotkey_bios_mask_show(struct device *dev,
 static struct device_attribute dev_attr_hotkey_bios_mask =
 	__ATTR(hotkey_bios_mask, S_IRUGO, hotkey_bios_mask_show, NULL);
 
+/* sysfs hotkey all_mask ----------------------------------------------- */
+static ssize_t hotkey_all_mask_show(struct device *dev,
+			   struct device_attribute *attr,
+			   char *buf)
+{
+	return snprintf(buf, PAGE_SIZE, "0x%08x\n", hotkey_all_mask);
+}
+
+static struct device_attribute dev_attr_hotkey_all_mask =
+	__ATTR(hotkey_all_mask, S_IRUGO, hotkey_all_mask_show, NULL);
+
+/* sysfs hotkey recommended_mask --------------------------------------- */
+static ssize_t hotkey_recommended_mask_show(struct device *dev,
+					    struct device_attribute *attr,
+					    char *buf)
+{
+	return snprintf(buf, PAGE_SIZE, "0x%08x\n",
+			hotkey_all_mask & ~hotkey_reserved_mask);
+}
+
+static struct device_attribute dev_attr_hotkey_recommended_mask =
+	__ATTR(hotkey_recommended_mask, S_IRUGO,
+		hotkey_recommended_mask_show, NULL);
+
 /* --------------------------------------------------------------------- */
 
 static struct attribute *hotkey_mask_attributes[] = {
 	&dev_attr_hotkey_mask.attr,
 	&dev_attr_hotkey_bios_enabled.attr,
 	&dev_attr_hotkey_bios_mask.attr,
+	&dev_attr_hotkey_all_mask.attr,
+	&dev_attr_hotkey_recommended_mask.attr,
 };
 
 static int __init hotkey_init(struct ibm_init_struct *iibm)
@@ -851,7 +879,7 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
 		str_supported(tp_features.hotkey));
 
 	if (tp_features.hotkey) {
-		hotkey_dev_attributes = create_attr_set(4, NULL);
+		hotkey_dev_attributes = create_attr_set(6, NULL);
 		if (!hotkey_dev_attributes)
 			return -ENOMEM;
 		res = add_to_attr_set(hotkey_dev_attributes,
@@ -867,6 +895,13 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
 		vdbg_printk(TPACPI_DBG_INIT, "hotkey masks are %s\n",
 			str_supported(tp_features.hotkey_mask));
 
+		if (tp_features.hotkey_mask) {
+			/* MHKA available in A31, R40, R40e, T4x, X31, and later */
+			if (!acpi_evalf(hkey_handle, &hotkey_all_mask,
+					"MHKA", "qd"))
+				hotkey_all_mask = 0x080cU; /* FN+F12, FN+F4, FN+F3 */
+		}
+
 		res = hotkey_get(&hotkey_orig_status, &hotkey_orig_mask);
 		if (!res && tp_features.hotkey_mask) {
 			res = add_many_to_attr_set(hotkey_dev_attributes,
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: export to sysfs the state of the radio slider switch

[Henrique de Moraes Holschuh]

Some ThinkPad models, notably the T60 and X60, have a slider switch to
enable and disable the radios.  The switch has the capability of
force-disabling the radios in hardware on most models, and it is supposed
to affect all radios (WLAN, WWAN, BlueTooth).

Export the switch state as a sysfs attribute, on ThinkPads where it is
available.

Thanks to Henning Schild for asking for this feature, and for tracking down
the EC register that holds the radio switch state.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
Cc: Henning Schild <henning-wy63DpzWjhr4ajHJ1XSv27NAH6kLmebB@public.gmane.org>
---
 Documentation/thinkpad-acpi.txt |    6 ++++++
 drivers/misc/thinkpad_acpi.c    |   38 ++++++++++++++++++++++++++++++++++++--
 drivers/misc/thinkpad_acpi.h    |    1 +
 3 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index 142a14f..fe26e50 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -227,6 +227,12 @@ sysfs notes:
 		supported hot keys, except those which are handled by
 		the firmware.  Echo it to hotkey_mask above, to use.
 
+	hotkey_radio_sw:
+		if the ThinkPad has a hardware radio switch, this
+		attribute will read 0 if the switch is in the "radios
+		disabled" postition, and 1 if the switch is in the
+		"radios enabled" position.
+
 
 Bluetooth
 ---------
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 8c08868..3cf37bb 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -733,6 +733,13 @@ static u32 hotkey_reserved_mask = 0x00778000;
 
 static struct attribute_set *hotkey_dev_attributes;
 
+static int hotkey_get_wlsw(int *status)
+{
+	if (!acpi_evalf(hkey_handle, status, "WLSW", "d"))
+		return -EIO;
+	return 0;
+}
+
 /* sysfs hotkey enable ------------------------------------------------- */
 static ssize_t hotkey_enable_show(struct device *dev,
 			   struct device_attribute *attr,
@@ -853,6 +860,22 @@ static struct device_attribute dev_attr_hotkey_recommended_mask =
 	__ATTR(hotkey_recommended_mask, S_IRUGO,
 		hotkey_recommended_mask_show, NULL);
 
+/* sysfs hotkey radio_sw ----------------------------------------------- */
+static ssize_t hotkey_radio_sw_show(struct device *dev,
+			   struct device_attribute *attr,
+			   char *buf)
+{
+	int res, s;
+	res = hotkey_get_wlsw(&s);
+	if (res < 0)
+		return res;
+
+	return snprintf(buf, PAGE_SIZE, "%d\n", !!s);
+}
+
+static struct device_attribute dev_attr_hotkey_radio_sw =
+	__ATTR(hotkey_radio_sw, S_IRUGO, hotkey_radio_sw_show, NULL);
+
 /* --------------------------------------------------------------------- */
 
 static struct attribute *hotkey_mask_attributes[] = {
@@ -866,6 +889,7 @@ static struct attribute *hotkey_mask_attributes[] = {
 static int __init hotkey_init(struct ibm_init_struct *iibm)
 {
 	int res;
+	int status;
 
 	vdbg_printk(TPACPI_DBG_INIT, "initializing hotkey subdriver\n");
 
@@ -879,7 +903,7 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
 		str_supported(tp_features.hotkey));
 
 	if (tp_features.hotkey) {
-		hotkey_dev_attributes = create_attr_set(6, NULL);
+		hotkey_dev_attributes = create_attr_set(7, NULL);
 		if (!hotkey_dev_attributes)
 			return -ENOMEM;
 		res = add_to_attr_set(hotkey_dev_attributes,
@@ -908,11 +932,21 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
 				hotkey_mask_attributes,
 				ARRAY_SIZE(hotkey_mask_attributes));
 		}
+
+		/* Not all thinkpads have a hardware radio switch */
+		if (!res && acpi_evalf(hkey_handle, &status, "WLSW", "qd")) {
+			tp_features.hotkey_wlsw = 1;
+			printk(IBM_INFO
+				"radio switch found; radios are %s\n",
+				enabled(status, 0));
+			res = add_to_attr_set(hotkey_dev_attributes,
+					&dev_attr_hotkey_radio_sw.attr);
+		}
+
 		if (!res)
 			res = register_attr_set_with_sysfs(
 					hotkey_dev_attributes,
 					&tpacpi_pdev->dev.kobj);
-
 		if (res)
 			return res;
 	}
diff --git a/drivers/misc/thinkpad_acpi.h b/drivers/misc/thinkpad_acpi.h
index e1a64f0..78ea4c8 100644
--- a/drivers/misc/thinkpad_acpi.h
+++ b/drivers/misc/thinkpad_acpi.h
@@ -228,6 +228,7 @@ static struct {
 	u16 bluetooth:1;
 	u16 hotkey:1;
 	u16 hotkey_mask:1;
+	u16 hotkey_wlsw:1;
 	u16 light:1;
 	u16 light_status:1;
 	u16 wan:1;
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: checkpoint sysfs interface version due to hotkey

[Henrique de Moraes Holschuh]

The change in the size of the hotkey mask, the hability to report the keys
that use the higher bits, and the addition of the hotkey_radio_sw attribute
are important enough features to warrant increasing the minor field of the
sysfs interface version.

Also, document a bit better how and when the thinkpad-acpi sysfs interface
version will be updated.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
---
 Documentation/thinkpad-acpi.txt |   17 +++++++++++++++++
 drivers/misc/thinkpad_acpi.c    |    2 +-
 2 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index fe26e50..7a06a27 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -134,6 +134,21 @@ end of this document.  Changes to the sysfs interface done by the kernel
 subsystems are not documented here, nor are they tracked by this
 attribute.
 
+Changes to the thinkpad-acpi sysfs interface are only considered
+non-experimental when they are submitted to Linux mainline, at which
+point the changes in this interface are documented and interface_version
+may be updated.  If you are using any thinkpad-acpi features not yet
+sent to mainline for merging, you do so on your own risk: these features
+may disappear, or be implemented in a different and incompatible way by
+the time they are merged in Linux mainline.
+
+Changes that are backwards-compatible by nature (e.g. the addition of
+attributes that do not change the way the other attributes work) do not
+always warrant an update of interface_version.  Therefore, one must
+expect that an attribute might not be there, and deal with it properly
+(an attribute not being there *is* a valid way to make it clear that a
+feature is not available in sysfs).
+
 Hot keys
 --------
 
@@ -989,3 +1004,5 @@ Sysfs interface changelog:
 
 0x000100:	Initial sysfs support, as a single platform driver and
 		device.
+0x000200:	Hot key support for 32 hot keys, and radio slider switch
+		support.
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 3cf37bb..4d71893 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -22,7 +22,7 @@
  */
 
 #define IBM_VERSION "0.14"
-#define TPACPI_SYSFS_VERSION 0x000100
+#define TPACPI_SYSFS_VERSION 0x000200
 
 /*
  *  Changelog:
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: register input device

[Henrique de Moraes Holschuh]

Register an input device to send input events to userspace.

This patch is based on a patch by Richard Hughes <hughsient-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
Cc: Richard Hughes <hughsient-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/misc/thinkpad_acpi.c |   32 +++++++++++++++++++++++++++++++-
 drivers/misc/thinkpad_acpi.h |    9 +++++++++
 2 files changed, 40 insertions(+), 1 deletions(-)

diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 4d71893..4427c99 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -510,13 +510,14 @@ static char *next_cmd(char **cmds)
 /****************************************************************************
  ****************************************************************************
  *
- * Device model: hwmon and platform
+ * Device model: input, hwmon and platform
  *
  ****************************************************************************
  ****************************************************************************/
 
 static struct platform_device *tpacpi_pdev;
 static struct class_device *tpacpi_hwmon;
+static struct input_dev *tpacpi_inputdev;
 
 static struct platform_driver tpacpi_pdriver = {
 	.driver = {
@@ -4363,6 +4364,20 @@ static int __init thinkpad_acpi_module_init(void)
 		thinkpad_acpi_module_exit();
 		return ret;
 	}
+	tpacpi_inputdev = input_allocate_device();
+	if (!tpacpi_inputdev) {
+		printk(IBM_ERR "unable to allocate input device\n");
+		thinkpad_acpi_module_exit();
+		return -ENOMEM;
+	} else {
+		/* Prepare input device, but don't register */
+		tpacpi_inputdev->name = "ThinkPad Extra Buttons";
+		tpacpi_inputdev->phys = IBM_DRVR_NAME "/input0";
+		tpacpi_inputdev->id.bustype = BUS_HOST;
+		tpacpi_inputdev->id.vendor = TPACPI_HKEY_INPUT_VENDOR;
+		tpacpi_inputdev->id.product = TPACPI_HKEY_INPUT_PRODUCT;
+		tpacpi_inputdev->id.version = TPACPI_HKEY_INPUT_VERSION;
+	}
 	for (i = 0; i < ARRAY_SIZE(ibms_init); i++) {
 		ret = ibm_init(&ibms_init[i]);
 		if (ret >= 0 && *ibms_init[i].param)
@@ -4372,6 +4387,14 @@ static int __init thinkpad_acpi_module_init(void)
 			return ret;
 		}
 	}
+	ret = input_register_device(tpacpi_inputdev);
+	if (ret < 0) {
+		printk(IBM_ERR "unable to register input device\n");
+		thinkpad_acpi_module_exit();
+		return ret;
+	} else {
+		tp_features.input_device_registered = 1;
+	}
 
 	return 0;
 }
@@ -4388,6 +4411,13 @@ static void thinkpad_acpi_module_exit(void)
 
 	dbg_printk(TPACPI_DBG_INIT, "finished subdriver exit path...\n");
 
+	if (tpacpi_inputdev) {
+		if (tp_features.input_device_registered)
+			input_unregister_device(tpacpi_inputdev);
+		else
+			input_free_device(tpacpi_inputdev);
+	}
+
 	if (tpacpi_hwmon)
 		hwmon_device_unregister(tpacpi_hwmon);
 
diff --git a/drivers/misc/thinkpad_acpi.h b/drivers/misc/thinkpad_acpi.h
index 78ea4c8..00f1bd7 100644
--- a/drivers/misc/thinkpad_acpi.h
+++ b/drivers/misc/thinkpad_acpi.h
@@ -39,6 +39,7 @@
 #include <linux/platform_device.h>
 #include <linux/hwmon.h>
 #include <linux/hwmon-sysfs.h>
+#include <linux/input.h>
 #include <asm/uaccess.h>
 
 #include <linux/dmi.h>
@@ -48,6 +49,7 @@
 #include <acpi/acpi_drivers.h>
 #include <acpi/acnamesp.h>
 
+#include <linux/pci_ids.h>
 
 /****************************************************************************
  * Main driver
@@ -98,6 +100,11 @@ static const char *str_supported(int is_supported);
 #define vdbg_printk(a_dbg_level, format, arg...)
 #endif
 
+/* Input IDs */
+#define TPACPI_HKEY_INPUT_VENDOR	PCI_VENDOR_ID_IBM
+#define TPACPI_HKEY_INPUT_PRODUCT	0x5054 /* "TP" */
+#define TPACPI_HKEY_INPUT_VERSION	0x4101
+
 /* ACPI HIDs */
 #define IBM_HKEY_HID    "IBM0068"
 #define IBM_PCI_HID     "PNP0A03"
@@ -161,6 +168,7 @@ static int parse_strtoul(const char *buf, unsigned long max,
 static struct platform_device *tpacpi_pdev;
 static struct class_device *tpacpi_hwmon;
 static struct platform_driver tpacpi_pdriver;
+static struct input_dev *tpacpi_inputdev;
 static int tpacpi_create_driver_attributes(struct device_driver *drv);
 static void tpacpi_remove_driver_attributes(struct device_driver *drv);
 
@@ -233,6 +241,7 @@ static struct {
 	u16 light_status:1;
 	u16 wan:1;
 	u16 fan_ctrl_status_undef:1;
+	u16 input_device_registered:1;
 } tp_features;
 
 static struct list_head tpacpi_all_drivers;
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: add input device support to hotkey subdriver

[Henrique de Moraes Holschuh]

Add input device support to the hotkey subdriver.

Hot keys that have a valid keycode mapping are reported through the input
layer if the input device is open.  Otherwise, they will be reported as
ACPI events, as they were before.

Scan codes are reported (using EV_MSC MSC_SCAN events) along with EV_KEY
KEY_UNKNOWN events.

For backwards compatibility purposes, hot keys that used to be reported
through ACPI events are not mapped to anything meaningful by default.
Userspace is supposed to remap them if it wants to use the input device for
hot key reporting.

This patch is based on a patch by Richard Hughes <hughsient-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
Cc: Richard Hughes <hughsient-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 Documentation/thinkpad-acpi.txt |  151 +++++++++++++++++++++++++++++++++++++++
 drivers/misc/thinkpad_acpi.c    |  108 +++++++++++++++++++++++++++-
 2 files changed, 255 insertions(+), 4 deletions(-)

diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index bd00d14..91d0892 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -167,6 +167,17 @@ All labeled Fn-Fx key combinations generate distinct events. In
 addition, the lid microswitch and some docking station buttons may
 also generate such events.
 
+Hot keys also generate regular keyboard key press/release events through
+the input layer in addition to the ibm/hotkey ACPI events.  The input
+layer support accepts the standard IOCTLs to remap the keycodes assigned
+to each hotkey.
+
+When the input device is open, the driver will suppress any ACPI hot key
+events that get translated into a meaningful input layer event, in order
+to avoid sending duplicate events to userspace.  Hot keys that are
+mapped to KEY_RESERVED are not translated, and will always generate only
+ACPI hot key event, and no input layer events.
+
 The bit mask allows some control over which hot keys generate ACPI
 events. Not all bits in the mask can be modified. Not all bits that can
 be modified do anything. Not all hot keys can be individually controlled
@@ -248,6 +259,146 @@ sysfs notes:
 		disabled" postition, and 1 if the switch is in the
 		"radios enabled" position.
 
+input layer notes:
+
+A Hot key is mapped to a single input layer EV_KEY event, possibly
+followed by an EV_MSC MSC_SCAN event that shall contain that key's scan
+code.  An EV_SYN event will always be generated to mark the end of the
+event block.
+
+Do not use the EV_MSC MSC_SCAN events to process keys.  They are to be
+used as a helper to remap keys, only.  They are particularly useful when
+remapping KEY_UNKNOWN keys.
+
+The events are available in an input device, with the following id:
+
+	Bus:		BUS_HOST
+	vendor:		0x1014 (PCI_VENDOR_ID_IBM)
+	product:	0x5054 ("TP")
+	version:	0x4101
+
+The version will have its LSB incremented if the keymap changes in a
+backwards-compatible way.  The MSB shall always be 0x41 for this input
+device.  If the MSB is not 0x41, do not use the device as described in
+this section, as it is either something else (e.g. another input device
+exported by a thinkpad driver, such as HDAPS) or its functionality has
+been changed in a non-backwards compatible way.
+
+Adding other event types for other functionalities shall be considered a
+backwards-compatible change for this input device.
+
+Thinkpad-acpi Hot Key event map (version 0x4101):
+
+ACPI	Scan
+event	code	Key		Notes
+
+0x1001	0x00	FN+F1		-
+0x1002	0x01	FN+F2		-
+
+0x1003	0x02	FN+F3		Many models always report this
+				hot key, even with hot keys
+				disabled or with Fn+F3 masked
+				off
+
+0x1004	0x03	FN+F4		Sleep button (ACPI sleep button
+				semanthics, i.e. sleep-to-RAM).
+				It is always generate some kind
+				of event, either the hot key
+				event or a ACPI sleep button
+				event. The firmware may
+				refuse to generate further FN+F4
+				key presses until a S3 or S4 ACPI
+				sleep cycle is performed or some
+				time passes.
+
+0x1005	0x04	FN+F5		Radio.  Enables/disables
+				the internal BlueTooth hardware
+				and W-WAN card if left in control
+				of the firmware.  Does not affect
+				the WLAN card.
+
+0x1006	0x05	FN+F6		-
+
+0x1007	0x06	FN+F7		Video output cycle.
+				Do you feel lucky today?
+
+0x1008	0x07	FN+F8		-
+	..	..		..
+0x100B	0x0A	FN+F11		-
+
+0x100C	0x0B	FN+F12		Sleep to disk.  You are always
+				supposed to handle it yourself,
+				either through the ACPI event,
+				or through a hotkey event.
+				The firmware may refuse to
+				generate further FN+F4 key
+				press events until a S3 or S4
+				ACPI sleep cycle is performed,
+				or some time passes.
+
+0x100D	0x0C	FN+BACKSPACE	-
+0x100E	0x0D	FN+INSERT	-
+0x100F	0x0E	FN+DELETE	-
+
+0x1010	0x0F	FN+HOME		Brightness up.  This key is
+				always handled by the firmware,
+				even when unmasked.  Just leave
+				it alone.
+0x1011	0x10	FN+END		Brightness down. This key is
+				always handled by the firmware,
+				even when unmasked.  Just leave
+				it alone.
+0x1012	0x11	FN+PGUP		Thinklight toggle.  This key is
+				always handled by the firmware,
+				even when unmasked.
+
+0x1013	0x12	FN+PGDOWN	-
+
+0x1014	0x13	FN+SPACE	Zoom key
+
+0x1015	0x14	VOLUME UP	Internal mixer volume up. This
+				key is always handled by the
+				firmware, even when unmasked.
+0x1016	0x15	VOLUME DOWN	Internal mixer volume up. This
+				key is always handled by the
+				firmware, even when unmasked.
+0x1017	0x16	MUTE		Mute internal mixer. This
+				key is always handled by the
+				firmware, even when unmasked.
+
+0x1018	0x17	THINKPAD	Thinkpad/Access IBM/Lenovo key
+
+0x1019	0x18	unknown
+..	..	..
+0x1020	0x1F	unknown
+
+The ThinkPad firmware does not allow one to differentiate when most hot
+keys are pressed or released (either that, or we don't know how to, yet).
+For these keys, the driver generates a set of events for a key press and
+immediately issues the same set of events for a key release.  It is
+unknown by the driver if the ThinkPad firmware triggered these events on
+hot key press or release, but the firmware will do it for either one, not
+both.
+
+If a key is mapped to KEY_RESERVED, it generates no input events at all,
+and it may generate a legacy thinkpad-acpi ACPI hotkey event.
+
+If a key is mapped to KEY_UNKNOWN, it generates an input event that
+includes an scan code, and it may also generate a legacy thinkpad-acpi
+ACPI hotkey event.
+
+If a key is mapped to anything else, it will only generate legacy
+thinkpad-acpi ACPI hotkey events if nobody has opened the input device.
+
+For userspace backwards-compatibility purposes, the keycode map is
+initially filled with KEY_RESERVED and KEY_UNKNOWN mappings for scan codes
+0x00 to 0x10 (and maybe others).
+
+Non hot-key ACPI HKEY event map:
+0x5001		Lid closed
+0x5002		Lid opened
+0x7000		Radio Switch may have changed state
+
 
 Bluetooth
 ---------
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 4427c99..5c1bea1 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -730,7 +730,31 @@ static struct ibm_struct thinkpad_acpi_driver_data = {
 static int hotkey_orig_status;
 static u32 hotkey_orig_mask;
 static u32 hotkey_all_mask;
-static u32 hotkey_reserved_mask = 0x00778000;
+static u32 hotkey_reserved_mask;
+
+static u16 hotkey_keycode_map[] = {
+	/* Scan Codes 0x00 to 0x0B: ACPI HKEY FN+F1..F12 */
+	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
+	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
+	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
+	/* Scan codes 0x0C to 0x0F: Other ACPI HKEY hot keys */
+	KEY_UNKNOWN,	/* 0x0C: FN+BACKSPACE */
+	KEY_UNKNOWN,	/* 0x0D: FN+INSERT */
+	KEY_UNKNOWN,	/* 0x0E: FN+DELETE */
+	KEY_RESERVED,	/* 0x0F: FN+HOME (brightness up) */
+	/* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */
+	KEY_RESERVED,	/* 0x10: FN+END (brightness down) */
+	KEY_RESERVED,	/* 0x11: FN+PGUP (thinklight toggle) */
+	KEY_UNKNOWN,	/* 0x12: FN+PGDOWN */
+	KEY_ZOOM,	/* 0x13: FN+SPACE (zoom) */
+	KEY_RESERVED,	/* 0x14: VOLUME UP */
+	KEY_RESERVED,	/* 0x15: VOLUME DOWN */
+	KEY_RESERVED,	/* 0x16: MUTE */
+	KEY_VENDOR,	/* 0x17: Thinkpad/AccessIBM/Lenovo */
+	/* (assignments unknown, please report if found) */
+	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
+	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
+};
 
 static struct attribute_set *hotkey_dev_attributes;
 
@@ -889,11 +913,13 @@ static struct attribute *hotkey_mask_attributes[] = {
 
 static int __init hotkey_init(struct ibm_init_struct *iibm)
 {
-	int res;
+	int res, i;
 	int status;
 
 	vdbg_printk(TPACPI_DBG_INIT, "initializing hotkey subdriver\n");
 
+	BUG_ON(!tpacpi_inputdev);
+
 	IBM_ACPIHANDLE_INIT(hkey);
 	mutex_init(&hotkey_mutex);
 
@@ -950,6 +976,23 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
 					&tpacpi_pdev->dev.kobj);
 		if (res)
 			return res;
+
+		set_bit(EV_KEY, tpacpi_inputdev->evbit);
+		set_bit(EV_MSC, tpacpi_inputdev->evbit);
+		set_bit(MSC_SCAN, tpacpi_inputdev->mscbit);
+		tpacpi_inputdev->keycodesize = sizeof(hotkey_keycode_map[0]);
+		tpacpi_inputdev->keycodemax = ARRAY_SIZE(hotkey_keycode_map);
+		tpacpi_inputdev->keycode = &hotkey_keycode_map;
+		for (i = 0; i < ARRAY_SIZE(hotkey_keycode_map); i++) {
+			if (hotkey_keycode_map[i] != KEY_RESERVED) {
+				set_bit(hotkey_keycode_map[i],
+					tpacpi_inputdev->keybit);
+			} else {
+				if (i < sizeof(hotkey_reserved_mask)*8)
+					hotkey_reserved_mask |= 1 << i;
+			}
+		}
+
 	}
 
 	return (tp_features.hotkey)? 0 : 1;
@@ -972,12 +1015,69 @@ static void hotkey_exit(void)
 	}
 }
 
+static void tpacpi_input_send_key(unsigned int scancode,
+				  unsigned int keycode)
+{
+	if (keycode != KEY_RESERVED) {
+		input_report_key(tpacpi_inputdev, keycode, 1);
+		if (keycode == KEY_UNKNOWN)
+			input_event(tpacpi_inputdev, EV_MSC, MSC_SCAN,
+				    scancode);
+		input_sync(tpacpi_inputdev);
+
+		input_report_key(tpacpi_inputdev, keycode, 0);
+		if (keycode == KEY_UNKNOWN)
+			input_event(tpacpi_inputdev, EV_MSC, MSC_SCAN,
+				    scancode);
+		input_sync(tpacpi_inputdev);
+	}
+}
+
 static void hotkey_notify(struct ibm_struct *ibm, u32 event)
 {
-	int hkey;
+	u32 hkey;
+	unsigned int keycode, scancode;
+	int sendacpi = 1;
 
 	if (event == 0x80 && acpi_evalf(hkey_handle, &hkey, "MHKP", "d")) {
-		acpi_bus_generate_event(ibm->acpi->device, event, hkey);
+		if (tpacpi_inputdev->users > 0) {
+			switch (hkey >> 12) {
+			case 1:
+				/* 0x1000-0x1FFF: key presses */
+				scancode = hkey & 0xfff;
+				if (scancode > 0 && scancode < 0x21) {
+					scancode--;
+					keycode = hotkey_keycode_map[scancode];
+					tpacpi_input_send_key(scancode, keycode);
+					sendacpi = (keycode == KEY_RESERVED
+						|| keycode == KEY_UNKNOWN);
+				} else {
+					printk(IBM_ERR
+					       "hotkey 0x%04x out of range for keyboard map\n",
+					       hkey);
+				}
+				break;
+			case 5:
+				/* 0x5000-0x5FFF: LID */
+				/* we don't handle it through this path, just
+				 * eat up known LID events */
+				if (hkey != 0x5001 && hkey != 0x5002) {
+					printk(IBM_ERR
+						"unknown LID-related hotkey event: 0x%04x\n",
+						hkey);
+				}
+				break;
+			default:
+				/* case 2: dock-related */
+				/*	0x2305 - T43 waking up due to bay lever eject while aslept */
+				/* case 3: ultra-bay related. maybe bay in dock? */
+				/*	0x3003 - T43 after wake up by bay lever eject (0x2305) */
+				printk(IBM_NOTICE "unhandled hotkey event 0x%04x\n", hkey);
+			}
+		}
+
+		if (sendacpi)
+			acpi_bus_generate_event(ibm->acpi->device, event, hkey);
 	} else {
 		printk(IBM_ERR "unknown hotkey notification event %d\n", event);
 		acpi_bus_generate_event(ibm->acpi->device, event, 0);
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: ACPI: thinkpad-acpi: add input device support to hotkey subdriver

[Matthew Garrett]

On Sat, Jul 14, 2007 at 11:11:59AM -0300, Henrique de Moraes Holschuh wrote:

> +static u16 hotkey_keycode_map[] = {
> +	/* Scan Codes 0x00 to 0x0B: ACPI HKEY FN+F1..F12 */
> +	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> +	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> +	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> +	/* Scan codes 0x0C to 0x0F: Other ACPI HKEY hot keys */
> +	KEY_UNKNOWN,	/* 0x0C: FN+BACKSPACE */
> +	KEY_UNKNOWN,	/* 0x0D: FN+INSERT */
> +	KEY_UNKNOWN,	/* 0x0E: FN+DELETE */
> +	KEY_RESERVED,	/* 0x0F: FN+HOME (brightness up) */

KEY_BRIGHTNESSUP

> +	/* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */
> +	KEY_RESERVED,	/* 0x10: FN+END (brightness down) */

KEY_BRIGHTNESSDOWN

> +	KEY_RESERVED,	/* 0x11: FN+PGUP (thinklight toggle) */
> +	KEY_UNKNOWN,	/* 0x12: FN+PGDOWN */
> +	KEY_ZOOM,	/* 0x13: FN+SPACE (zoom) */
> +	KEY_RESERVED,	/* 0x14: VOLUME UP */

KEY_VOLUMEUP

> +	KEY_RESERVED,	/* 0x15: VOLUME DOWN */

KEY_VOLUMEDOWN

> +	KEY_RESERVED,	/* 0x16: MUTE */

KEY_MUTE

Why aren't we setting these sensibly?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: ACPI: thinkpad-acpi: add input device support to hotkey subdriver

[Henrique de Moraes Holschuh]

On Sat, 14 Jul 2007, Matthew Garrett wrote:
> On Sat, Jul 14, 2007 at 11:11:59AM -0300, Henrique de Moraes Holschuh wrote:
> > +static u16 hotkey_keycode_map[] = {
> > +	/* Scan Codes 0x00 to 0x0B: ACPI HKEY FN+F1..F12 */
> > +	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > +	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > +	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > +	/* Scan codes 0x0C to 0x0F: Other ACPI HKEY hot keys */
> > +	KEY_UNKNOWN,	/* 0x0C: FN+BACKSPACE */
> > +	KEY_UNKNOWN,	/* 0x0D: FN+INSERT */
> > +	KEY_UNKNOWN,	/* 0x0E: FN+DELETE */
> > +	KEY_RESERVED,	/* 0x0F: FN+HOME (brightness up) */
> 
> KEY_BRIGHTNESSUP

Only if I start filtering it out when disabled by the mask.  This key is not
to be sent to userspace unless explicitly configured to do so by something
that KNOWS it will handle it right (hal).

> > +	/* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */
> > +	KEY_RESERVED,	/* 0x10: FN+END (brightness down) */
> 
> KEY_BRIGHTNESSDOWN

See above.

> > +	KEY_RESERVED,	/* 0x11: FN+PGUP (thinklight toggle) */
> > +	KEY_UNKNOWN,	/* 0x12: FN+PGDOWN */
> > +	KEY_ZOOM,	/* 0x13: FN+SPACE (zoom) */
> > +	KEY_RESERVED,	/* 0x14: VOLUME UP */
> 
> KEY_VOLUMEUP

No.  This is handled in firmware in IBM thinkpads, and userspace only screws
it up.  I am tired of watching people get this routed to the AC97 mixer by
default.  That is a fringe configuration that only makes sense when using a
dock, and with the audio tied to the dock's audio port, in *all* thinkpads
but (_maybe_) the *61.

Let hal enable it if it needs it for OSD, and I sure hope HAL is wise enough
to do passive handling only for the events that come from the thinkpad event
device, because if one has an external multimedia keyboard, its volume keys
should go to the AC97/HDA mixer.

Same goes for volume down and mute.

> Why aren't we setting these sensibly?

They are, in presence of an userspace that thinks it knows better, and just
screws it up all the time.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: ACPI: thinkpad-acpi: add input device support to hotkey subdriver

[Matthew Garrett]

On Sun, Jul 15, 2007 at 03:12:33PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 14 Jul 2007, Matthew Garrett wrote:
> > KEY_BRIGHTNESSUP
> 
> Only if I start filtering it out when disabled by the mask.  This key is not
> to be sent to userspace unless explicitly configured to do so by something
> that KNOWS it will handle it right (hal).

I'm not aware of any other application that uses it.

> > KEY_VOLUMEUP
> 
> No.  This is handled in firmware in IBM thinkpads, and userspace only screws
> it up.  I am tired of watching people get this routed to the AC97 mixer by
> default.  That is a fringe configuration that only makes sense when using a
> dock, and with the audio tied to the dock's audio port, in *all* thinkpads
> but (_maybe_) the *61.

It should either generate a KEY_VOLUMEUP or it should generate something 
explicitly defined as KEY_VOLUMEUP_PASSIVE. The proposed configuration 
(send something that does nothing, but include an arbitrary scancode) 
adds complexity and does nothing other than avoid a (harmless) odd 
result.

> Let hal enable it if it needs it for OSD, and I sure hope HAL is wise enough
> to do passive handling only for the events that come from the thinkpad event
> device, because if one has an external multimedia keyboard, its volume keys
> should go to the AC97/HDA mixer.

That's fine. One will be coming from the i8042 (or USB) and the other 
will be coming from thinkpad_acpi. We already have the information 
needed to do something sensible there - we don't need to have different 
keycodes to determine which is which.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: ACPI: thinkpad-acpi: add input device support to hotkey subdriver

[Henrique de Moraes Holschuh]

On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > No.  This is handled in firmware in IBM thinkpads, and userspace only screws
> > it up.  I am tired of watching people get this routed to the AC97 mixer by
> > default.  That is a fringe configuration that only makes sense when using a
> > dock, and with the audio tied to the dock's audio port, in *all* thinkpads
> > but (_maybe_) the *61.
> 
> It should either generate a KEY_VOLUMEUP or it should generate something 
> explicitly defined as KEY_VOLUMEUP_PASSIVE. The proposed configuration 

Well, it will someday (2.6.24)? be an alsa mixer.  The mixer generates
events when changed, and you could get that info from there.

I'd be happy to provide a VOLUMEUP_PASSIVE, but it doesn't exist.  I'd be
even happier to have an EV_KEYNOTIFY to use instead of EV_KEY that has the
explicit notion that "something else will handle the active effects of this
key, this is a FYI event only".

> (send something that does nothing, but include an arbitrary scancode) 

It doesn't send anything on the input device if it is set to KEY_RESERVED.
It does send an ACPI ibm/hotkey event, but that is a compatibility
interface.

> adds complexity and does nothing other than avoid a (harmless) odd 
> result.

I do not consider screwing up the mixer handling a harmless result.

> > Let hal enable it if it needs it for OSD, and I sure hope HAL is wise enough
> > to do passive handling only for the events that come from the thinkpad event
> > device, because if one has an external multimedia keyboard, its volume keys
> > should go to the AC97/HDA mixer.
> 
> That's fine. One will be coming from the i8042 (or USB) and the other 
> will be coming from thinkpad_acpi. We already have the information 
> needed to do something sensible there - we don't need to have different 
> keycodes to determine which is which.

Good.   Not that I'd have anything against giving you an explicitly
*passive* event, but there is no such a beast.  Give one to me, and I shall
use it.

Until then, since the default meaning of *all* KEY_ events are active in
nature, I am against the idea of generating events that are to be handled in
a passive way, by default.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: add input device support to hotkey subdriver

[Matthew Garrett]

On Sun, Jul 15, 2007 at 05:03:38PM -0300, Henrique de Moraes Holschuh wrote:

> I do not consider screwing up the mixer handling a harmless result.

We've shipped in this configuration for over a year. Total number of 
bugs filed? None. It's not ideal, but it's simply not true that it 
results in a high level of user confusion or a screwed up mixer.

(Context for those not aware of it - Thinkpad hardware has two mixers. 
One is associated with the sound codec and is controllable via ALSA. The 
other is Thinkpad-specific and is controlled via the hotkeys. Sending 
KEY_VOLUMEUP and KEY_VOLUMEDOWN results in both of these mixers being 
changed. However, since they're both changed in the same direction, 
nobody seems to be especially unhappy about this)

> Until then, since the default meaning of *all* KEY_ events are active in
> nature, I am against the idea of generating events that are to be handled in
> a passive way, by default.

That's simply not true. Userspace already interprets the brightness keys 
differently depending on the hardware type.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: add input device support to hotkey subdriver

[Henrique de Moraes Holschuh]

On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 05:03:38PM -0300, Henrique de Moraes Holschuh wrote:
> > I do not consider screwing up the mixer handling a harmless result.
> 
> We've shipped in this configuration for over a year. Total number of 
> bugs filed? None. It's not ideal, but it's simply not true that it 
> results in a high level of user confusion or a screwed up mixer.

Well, I got one report.

> > Until then, since the default meaning of *all* KEY_ events are active in
> > nature, I am against the idea of generating events that are to be handled in
> > a passive way, by default.
> 
> That's simply not true. Userspace already interprets the brightness keys 
> differently depending on the hardware type.

*HAL* does.  HAL is *not* all there is to userspace.  The input layer is not
an interface between the kernel and HAL, it is an interface between kernel
and userspace.

Add that knowledge to the input layer, and I will agree.  Add it to every
consumer of input events, and I will concede.  Until then, it is good that
HAL can overcome the lack of such information in the input layer, but that
doesn't make it the right way to use the input layer.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: add input device support to hotkey subdriver

[Matthew Garrett]

On Sun, Jul 15, 2007 at 05:59:34PM -0300, Henrique de Moraes Holschuh wrote:

> *HAL* does.  HAL is *not* all there is to userspace.  The input layer is not
> an interface between the kernel and HAL, it is an interface between kernel
> and userspace.

Hal is the only piece of userspace that knows how to speak to more than 
one type of backlight in any useful way, which makes it the de-facto 
reference for how userspace interprets these keys.

> Add that knowledge to the input layer, and I will agree.  Add it to every
> consumer of input events, and I will concede.  Until then, it is good that
> HAL can overcome the lack of such information in the input layer, but that
> doesn't make it the right way to use the input layer.

The fact that keys share event codes doesn't mean that these keycodes 
are going to have identical semantics on all hardware. One solution to 
that would be to avoid ever sending these keycodes, but that would make 
having them defined in the first place a bit silly. Since they /are/ 
there, it makes sense to use them.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: add input device support to hotkey subdriver

[Henrique de Moraes Holschuh]

On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 05:59:34PM -0300, Henrique de Moraes Holschuh wrote:
> > *HAL* does.  HAL is *not* all there is to userspace.  The input layer is not
> > an interface between the kernel and HAL, it is an interface between kernel
> > and userspace.
> 
> Hal is the only piece of userspace that knows how to speak to more than 
> one type of backlight in any useful way, which makes it the de-facto 
> reference for how userspace interprets these keys.

Since when does system-specific programs not count?

Anyway, the idea of "special cases" that are not exposed anywhere and
requires out-of-band information to be handled correctly is just broken IMO.
This goes triple for an interface whose only canon documentation is the
current kernel code, so you can't even tell people to read somewhere how to
properly use it.

Since we have detected the need for passive events, I'd much rather that
information was added to the input layer itself, instead of being
synthesized later.

> > Add that knowledge to the input layer, and I will agree.  Add it to every
> > consumer of input events, and I will concede.  Until then, it is good that
> > HAL can overcome the lack of such information in the input layer, but that
> > doesn't make it the right way to use the input layer.
> 
> The fact that keys share event codes doesn't mean that these keycodes 
> are going to have identical semantics on all hardware. One solution to 
> that would be to avoid ever sending these keycodes, but that would make 
> having them defined in the first place a bit silly. Since they /are/ 
> there, it makes sense to use them.

I see a keycode defined in the USB HID spec for use in stuff that only knows
active handling -- passive doesn't even make any sense for them -- and its
reflect on the kernel input layer.

There _are_ a few platforms where *one* of the built-in devices need a
different handling, and that's just because the firmware won't cooperate.
But if I plug a USB keyboard on a thinkpad, for example, I need the proper
(active) handling of the event.

I definately think "avoid ever sending these keycodes" in this instance is
the right way to go, until we can actually issue a "this is a passive key
press" event.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: ACPI: thinkpad-acpi: add input device support to hotkey subdriver

[Matthew Garrett]

On Sun, Jul 15, 2007 at 06:54:53PM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > Hal is the only piece of userspace that knows how to speak to more than 
> > one type of backlight in any useful way, which makes it the de-facto 
> > reference for how userspace interprets these keys.
> 
> Since when does system-specific programs not count?

If they're Thinkpad-specific, they're already doing the right thing. If 
they're specific to another model, they're not running on a Thinkpad.

> > The fact that keys share event codes doesn't mean that these keycodes 
> > are going to have identical semantics on all hardware. One solution to 
> > that would be to avoid ever sending these keycodes, but that would make 
> > having them defined in the first place a bit silly. Since they /are/ 
> > there, it makes sense to use them.
> 
> I see a keycode defined in the USB HID spec for use in stuff that only knows
> active handling -- passive doesn't even make any sense for them -- and its
> reflect on the kernel input layer.
> 
> There _are_ a few platforms where *one* of the built-in devices need a
> different handling, and that's just because the firmware won't cooperate.
> But if I plug a USB keyboard on a thinkpad, for example, I need the proper
> (active) handling of the event.

That's fine. You know that the event came from an external keyboard, so 
you know that it has to be handled actively.

> I definately think "avoid ever sending these keycodes" in this instance is
> the right way to go, until we can actually issue a "this is a passive key
> press" event.

As I said, the existing userspace implementation disagrees. I'd prefer 
to avoid breaking that.
-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: add input device support to hotkey subdriver

[Henrique de Moraes Holschuh]

On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 06:54:53PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > > Hal is the only piece of userspace that knows how to speak to more than 
> > > one type of backlight in any useful way, which makes it the de-facto 
> > > reference for how userspace interprets these keys.
> > 
> > Since when does system-specific programs not count?
> 
> If they're Thinkpad-specific, they're already doing the right thing. If 
> they're specific to another model, they're not running on a Thinkpad.

True. I missed that angle.

> > > The fact that keys share event codes doesn't mean that these keycodes 
> > > are going to have identical semantics on all hardware. One solution to 
> > > that would be to avoid ever sending these keycodes, but that would make 
> > > having them defined in the first place a bit silly. Since they /are/ 
> > > there, it makes sense to use them.
> > 
> > I see a keycode defined in the USB HID spec for use in stuff that only knows
> > active handling -- passive doesn't even make any sense for them -- and its
> > reflect on the kernel input layer.
> > 
> > There _are_ a few platforms where *one* of the built-in devices need a
> > different handling, and that's just because the firmware won't cooperate.
> > But if I plug a USB keyboard on a thinkpad, for example, I need the proper
> > (active) handling of the event.
> 
> That's fine. You know that the event came from an external keyboard, so 
> you know that it has to be handled actively.
> 
> > I definately think "avoid ever sending these keycodes" in this instance is
> > the right way to go, until we can actually issue a "this is a passive key
> > press" event.
> 
> As I said, the existing userspace implementation disagrees. I'd prefer 
> to avoid breaking that.

I have not nearly as much patience as you do with broken designs.  The input
layer interface was *not* made to convey the idea of passive keys.  *This*
was not broken (it just wasn't generic enough, and the fact that you don't
have an extensible "flags" field that you could use to extend it *is* the
real design shortcoming).

However, abusing that interface to send passive events *is* broken.
Especially because the other side has to know by itself what is active and
what is passive, and this changes from system model to model, and maybe even
from bios version to bios version.

IMHO, it should NEVER have been done like that in the first place.  You
start walking such a road, you will have to work thrice to fix it.  The
correct thing to do is to fix the interface.  It can be done in a backwards
compatible way.  It won't be anywhere as pretty as it could have been if
input layer events were friendly to being extended, but it can be done.

Please correct me if I am mistaken, but AFAIK, nothing I do in thinkpad-acpi
that doesn't start generating *new* passive-masquerated-as-active events
around will break any old system, as these are ALREADY working using tpb or
somesuch. 

Since thinkpad-acpi not generating such broken events by default that
doesn't stop (or even make it more difficult) for new HAL to get the driver
to produce them if it wants to, and it also doesn't stop old HAL from
working just fine (using tpb, etc), it looks to me like the best path.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: add input device support to hotkey subdriver

[Dmitry Torokhov]

On 7/15/07, Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:
> On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > On Sun, Jul 15, 2007 at 05:59:34PM -0300, Henrique de Moraes Holschuh wrote:
> > > *HAL* does.  HAL is *not* all there is to userspace.  The input layer is not
> > > an interface between the kernel and HAL, it is an interface between kernel
> > > and userspace.
> >
> > Hal is the only piece of userspace that knows how to speak to more than
> > one type of backlight in any useful way, which makes it the de-facto
> > reference for how userspace interprets these keys.
>
> Since when does system-specific programs not count?
>
> Anyway, the idea of "special cases" that are not exposed anywhere and
> requires out-of-band information to be handled correctly is just broken IMO.
> This goes triple for an interface whose only canon documentation is the
> current kernel code, so you can't even tell people to read somewhere how to
> properly use it.
>
> Since we have detected the need for passive events, I'd much rather that
> information was added to the input layer itself, instead of being
> synthesized later.
>

I am unconvinced that input layer is the proper place to add such
information. These are events signalling state change of some device.
In case of volume changes these events do not refect change in
keyboard state but rather some other device (sound card) so I would
expect these events be coming from there.
I also do not want to convert input layer into kitchen sink of generic
userspace notifications. Laptop "battery removed" does not belong to
input. "Network cable removed" does not belong to input. "Hard driver
dying" does not belong to input.

> > > Add that knowledge to the input layer, and I will agree.  Add it to every
> > > consumer of input events, and I will concede.  Until then, it is good that
> > > HAL can overcome the lack of such information in the input layer, but that
> > > doesn't make it the right way to use the input layer.
> >
> > The fact that keys share event codes doesn't mean that these keycodes
> > are going to have identical semantics on all hardware. One solution to
> > that would be to avoid ever sending these keycodes, but that would make
> > having them defined in the first place a bit silly. Since they /are/
> > there, it makes sense to use them.
>
> I see a keycode defined in the USB HID spec for use in stuff that only knows
> active handling -- passive doesn't even make any sense for them -- and its
> reflect on the kernel input layer.
>
> There _are_ a few platforms where *one* of the built-in devices need a
> different handling, and that's just because the firmware won't cooperate.
> But if I plug a USB keyboard on a thinkpad, for example, I need the proper
> (active) handling of the event.
>
> I definately think "avoid ever sending these keycodes" in this instance is
> the right way to go, until we can actually issue a "this is a passive key
> press" event.
>

How do you know that this is a "passive keypress"? Can you put another
(better) soundcard in a docking station? Woudl the firmware still
control that card (doubtful)? Do we want the same keys to control that
card's volume?

-- 
Dmitry

Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: add input device support to hotkey subdriver

[Matthew Garrett]

On Mon, Jul 16, 2007 at 11:46:26AM -0400, Dmitry Torokhov wrote:

> How do you know that this is a "passive keypress"? Can you put another
> (better) soundcard in a docking station? Woudl the firmware still
> control that card (doubtful)? Do we want the same keys to control that
> card's volume?

This is absolutely possible. In that case I'd expect the hotkeys to 
start controlling the card mixer's volume, but that's a policy decision 
that would have to be taken in userspace by an application aware of 
everything that's happened.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: add input device support to hotkey subdriver

[Henrique de Moraes Holschuh]

On Mon, 16 Jul 2007, Matthew Garrett wrote:
> On Mon, Jul 16, 2007 at 11:46:26AM -0400, Dmitry Torokhov wrote:
> > How do you know that this is a "passive keypress"? Can you put another
> > (better) soundcard in a docking station? Woudl the firmware still
> > control that card (doubtful)? Do we want the same keys to control that
> > card's volume?
> 
> This is absolutely possible. In that case I'd expect the hotkeys to 
> start controlling the card mixer's volume, but that's a policy decision 
> that would have to be taken in userspace by an application aware of 
> everything that's happened.

The moment you screw up with the thinkpad builtin mixer, you are screwing
with the emergency notification system (system beeps).  They go *only*
through that mixer, and their signal is not routed through the builtin AC97
(and probably not through HDA either) mixers.   I would stay well away from
trying to override what these buttons do.

In fact, the thinkpad volume buttons are (in most thinkpads, I don't speak
for the new *61 models, they may be different) the "button version" of a
small volume dial near the headphone jack.

They were NOT made to be used in any other way, they DO NOT work in any
other way in Windows, and the firmware does NOT cooperate to let you use
them in any other way.

This whole issue is mainly caused by a refusal to understand this simple
fact.  THOSE BUTTONS ARE NOT GENERIC VOLUME CONTROL BUTTONS unless you hack
the firmware on anything but the very newest X61, R61 and T61... and maybe
even on them.

(and if you hack the firmware, you can get thinkpad-acpi to do what you want
with just the right sysfs setting).

IMO, if you want to use hot keys to control the AC97/HDA/soundcard mixer
volume in a typical thinkpad where the volume buttons are handled in
firmware, just assign Fn+Insert and Fn+delete to VOLUME_UP and VOLUME_DOWN,
they are right to the side of HOME/END (brightness up/down) anyway.

Anyway, if the input layer is really not the place for "passive key
presses", then my decision to not issue input events for such stuff is the
correct one.

Brightness can be notified through ACPI (ACPI 3.0b has standard events for
this), or it could be done through an improved backlight sysfs class.  It
will require work either way, because you don't want ACPI video processing
these synthezised events, or because you need to get backlight to be
poll()/select() or inotify()-friendly if you don't want to add another
dumbass userspace polling loop.

Built-in headphone/speaker volume can be notified and controlled through an
ALSA mixer.  It won't be a nice poll-less thing, but I can trap the ACPI hot
key events as a hint to update the mixer state, and if ALSA lets me do it,
issue mixer changed notifications.

And thinklight toggle key presses can be notified through the LED class,
although that one is such an useless notification, that I simply don't know
if I should bother with it.

That covers all thinkpad "passive" EV_KEY events.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: add input device support to hotkey subdriver

[Matthew Garrett]

On Mon, Jul 16, 2007 at 03:19:11PM -0300, Henrique de Moraes Holschuh wrote:

> Anyway, if the input layer is really not the place for "passive key
> presses", then my decision to not issue input events for such stuff is the
> correct one.

That wasn't my interpretation of what Dmitry said - it's not a generic 
event layer, but when you have keys that generate events that would be 
useful to userspace then I think it makes absolute sense to send them.

> Brightness can be notified through ACPI (ACPI 3.0b has standard events for
> this), or it could be done through an improved backlight sysfs class.  It
> will require work either way, because you don't want ACPI video processing
> these synthezised events, or because you need to get backlight to be
> poll()/select() or inotify()-friendly if you don't want to add another
> dumbass userspace polling loop.

The simple fact of the matter is that when you get outside the range of 
the standard qwerty keys, the semantics of the buttons become hardware 
dependent. The behaviour of KEY_SWITCHVIDEOMODE is going to vary wildly 
between hardware. Wlan control may be active or passive (and the 
standard adopted there appears to be to send KEY_WLAN regardless). Dells 
will trigger a dock unplug event automatically if you hit the dock 
unplug button - Thinkpads won't.

I think it makes absolute sense to get these notifications in the same 
way wherever possible, and then let userspace handle them as 
appropriate. On modern Thinkpads I need to alter whichever backlight 
interface is most appropriate to the machine in question (something that 
itself is going to differ between Thinkpads and, say, Macs) whereas in 
older ones I just want to pop up a notification with the new brightness. 

I realise your concern about breaking existing userspace, but as far as 
I can tell there /is/ no existing userspace to break. Hal does the right 
thing already, and there's nothing else that listens for key brightness 
events on Thinkpads.

> Built-in headphone/speaker volume can be notified and controlled through an
> ALSA mixer.  It won't be a nice poll-less thing, but I can trap the ACPI hot
> key events as a hint to update the mixer state, and if ALSA lets me do it,
> issue mixer changed notifications.

ALSA lets you do that.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

ACPI: thinkpad-acpi: add power-management handler capability

[Henrique de Moraes Holschuh]

Some subdrivers could benefit from resume handling, so add the
infrastructure for simple resume handling.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
---
 drivers/misc/thinkpad_acpi.c |   16 ++++++++++++++++
 drivers/misc/thinkpad_acpi.h |    1 +
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index c86b228..78914bf 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -519,11 +519,27 @@ static struct platform_device *tpacpi_pdev;
 static struct class_device *tpacpi_hwmon;
 static struct input_dev *tpacpi_inputdev;
 
+
+static int tpacpi_resume_handler(struct platform_device *pdev)
+{
+	struct ibm_struct *ibm, *itmp;
+
+	list_for_each_entry_safe(ibm, itmp,
+				 &tpacpi_all_drivers,
+				 all_drivers) {
+		if (ibm->resume)
+			(ibm->resume)();
+	}
+
+	return 0;
+}
+
 static struct platform_driver tpacpi_pdriver = {
 	.driver = {
 		.name = IBM_DRVR_NAME,
 		.owner = THIS_MODULE,
 	},
+	.resume = tpacpi_resume_handler,
 };
 
 
diff --git a/drivers/misc/thinkpad_acpi.h b/drivers/misc/thinkpad_acpi.h
index 00f1bd7..c5c1316 100644
--- a/drivers/misc/thinkpad_acpi.h
+++ b/drivers/misc/thinkpad_acpi.h
@@ -205,6 +205,7 @@ struct ibm_struct {
 	int (*read) (char *);
 	int (*write) (char *);
 	void (*exit) (void);
+	void (*resume) (void);
 
 	struct list_head all_drivers;
 
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: export EV_SW SW_RADIO events

[Henrique de Moraes Holschuh]

The expected user case for the radio slider switch on a ThinkPad includes
interfacing to applications, so that the user gets an offer to find and
associate with a wireless network when the switch is changed from disabled
to enabled (ThinkVantage suite).

Export the information about the switch state, and switch change events as
an EV_SW SW_RADIO event over the input layer.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
Cc: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Ivo van Doorn <ivdoorn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Richard Hughes <hughsient-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/misc/thinkpad_acpi.c |   28 ++++++++++++++++++++++++++++
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 78914bf..cfef218 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -1014,6 +1014,11 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
 			}
 		}
 
+		if (tp_features.hotkey_wlsw) {
+			set_bit(EV_SW, tpacpi_inputdev->evbit);
+			set_bit(SW_RADIO, tpacpi_inputdev->swbit);
+		}
+
 #ifdef CONFIG_THINKPAD_ACPI_INPUT_ENABLED
 		dbg_printk(TPACPI_DBG_INIT,
 				"enabling hot key handling\n");
@@ -1062,6 +1067,15 @@ static void tpacpi_input_send_key(unsigned int scancode,
 	}
 }
 
+static void tpacpi_input_send_radiosw(void)
+{
+	int wlsw;
+
+	if (tp_features.hotkey_wlsw && !hotkey_get_wlsw(&wlsw))
+		input_report_switch(tpacpi_inputdev,
+				    SW_RADIO, !!wlsw);
+}
+
 static void hotkey_notify(struct ibm_struct *ibm, u32 event)
 {
 	u32 hkey;
@@ -1096,6 +1110,14 @@ static void hotkey_notify(struct ibm_struct *ibm, u32 event)
 						hkey);
 				}
 				break;
+			case 7:
+				/* 0x7000-0x7FFF: misc */
+				if (tp_features.hotkey_wlsw && hkey == 0x7000) {
+						tpacpi_input_send_radiosw();
+						sendacpi = 0;
+					break;
+				}
+				/* fallthrough to default */
 			default:
 				/* case 2: dock-related */
 				/*	0x2305 - T43 waking up due to bay lever eject while aslept */
@@ -1113,6 +1135,11 @@ static void hotkey_notify(struct ibm_struct *ibm, u32 event)
 	}
 }
 
+static void hotkey_resume(void)
+{
+	tpacpi_input_send_radiosw();
+}
+
 /*
  * Call with hotkey_mutex held
  */
@@ -1240,6 +1267,7 @@ static struct ibm_struct hotkey_driver_data = {
 	.read = hotkey_read,
 	.write = hotkey_write,
 	.exit = hotkey_exit,
+	.resume = hotkey_resume,
 	.acpi = &ibm_hotkey_acpidriver,
 };
 
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: checkpoint sysfs interface version due to input layer

[Henrique de Moraes Holschuh]

The change in the way hotkey events are handled by default, and the use of
the input layer for the hotkey events are important enough features to
warrant increasing the major field of the sysfs interface version.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
---
 Documentation/thinkpad-acpi.txt |    4 ++++
 drivers/misc/thinkpad_acpi.c    |    2 +-
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index 5b59cf5..c670363 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -1157,3 +1157,7 @@ Sysfs interface changelog:
 		device.
 0x000200:	Hot key support for 32 hot keys, and radio slider switch
 		support.
+0x010000:	Hot keys are now handled by default over the input
+		layer, the radio switch generates input event EV_RADIO,
+		and the driver enables hot key handling by default in
+		the firmware.
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index cfef218..c1e6a01 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -22,7 +22,7 @@
  */
 
 #define IBM_VERSION "0.14"
-#define TPACPI_SYSFS_VERSION 0x000200
+#define TPACPI_SYSFS_VERSION 0x010000
 
 /*
  *  Changelog:
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: rename pci HID constant

[Henrique de Moraes Holschuh]

Rename an internal driver constant, on request by Len Brown.  Also,
document exactly what it is for.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
---
 drivers/misc/thinkpad_acpi.c |    7 +++++--
 drivers/misc/thinkpad_acpi.h |    1 -
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index c1e6a01..78e4110 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -2026,7 +2026,10 @@ static struct tp_acpi_drv_struct ibm_dock_acpidriver[2] = {
 	 .type = ACPI_SYSTEM_NOTIFY,
 	},
 	{
-	 .hid = IBM_PCI_HID,
+	/* THIS ONE MUST NEVER BE USED FOR DRIVER AUTOLOADING.
+	 * We just use it to get notifications of dock hotplug
+	 * in very old thinkpads */
+	 .hid = PCI_ROOT_HID_STRING,
 	 .notify = dock_notify,
 	 .handle = &pci_handle,
 	 .type = ACPI_SYSTEM_NOTIFY,
@@ -2085,7 +2088,7 @@ static int __init dock_init2(struct ibm_init_struct *iibm)
 static void dock_notify(struct ibm_struct *ibm, u32 event)
 {
 	int docked = dock_docked();
-	int pci = ibm->acpi->hid && strstr(ibm->acpi->hid, IBM_PCI_HID);
+	int pci = ibm->acpi->hid && strstr(ibm->acpi->hid, PCI_ROOT_HID_STRING);
 
 	if (event == 1 && !pci)	/* 570 */
 		acpi_bus_generate_event(ibm->acpi->device, event, 1);	/* button */
diff --git a/drivers/misc/thinkpad_acpi.h b/drivers/misc/thinkpad_acpi.h
index c5c1316..fee0421 100644
--- a/drivers/misc/thinkpad_acpi.h
+++ b/drivers/misc/thinkpad_acpi.h
@@ -107,7 +107,6 @@ static const char *str_supported(int is_supported);
 
 /* ACPI HIDs */
 #define IBM_HKEY_HID    "IBM0068"
-#define IBM_PCI_HID     "PNP0A03"
 
 /* ACPI helpers */
 static int __must_check acpi_evalf(acpi_handle handle,
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: ACPI: thinkpad-acpi: rename pci HID constant

[Matthew Garrett]

On Sat, Jul 14, 2007 at 11:12:04AM -0300, Henrique de Moraes Holschuh wrote:
> -	 .hid = IBM_PCI_HID,
> +	/* THIS ONE MUST NEVER BE USED FOR DRIVER AUTOLOADING.

Some rationale here would be good. There are no known devices where 
loading ibm-acpi is harmful.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: ACPI: thinkpad-acpi: rename pci HID constant

[Henrique de Moraes Holschuh]

On Sat, 14 Jul 2007, Matthew Garrett wrote:
> On Sat, Jul 14, 2007 at 11:12:04AM -0300, Henrique de Moraes Holschuh wrote:
> > -	 .hid = IBM_PCI_HID,
> > +	/* THIS ONE MUST NEVER BE USED FOR DRIVER AUTOLOADING.
> 
> Some rationale here would be good. There are no known devices where 
> loading ibm-acpi is harmful.

It is completely and utterly useless to autoload based on this.  You would
try to autoload it on every machine with a PCI root bridge, which is NOT a
bright idea at all.

Not to mention thinkpad-acpi uses this only on a extremely old model 570,
AFAIK.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: ACPI: thinkpad-acpi: rename pci HID constant

[Matthew Garrett]

On Sun, Jul 15, 2007 at 03:02:46PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 14 Jul 2007, Matthew Garrett wrote:
> > On Sat, Jul 14, 2007 at 11:12:04AM -0300, Henrique de Moraes Holschuh wrote:
> > > -	 .hid = IBM_PCI_HID,
> > > +	/* THIS ONE MUST NEVER BE USED FOR DRIVER AUTOLOADING.
> > 
> > Some rationale here would be good. There are no known devices where 
> > loading ibm-acpi is harmful.
> 
> It is completely and utterly useless to autoload based on this.  You would
> try to autoload it on every machine with a PCI root bridge, which is NOT a
> bright idea at all.

I meant the IBM0068 device. That doesn't appear to be used anywhere 
other than Thinkpads.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: ACPI: thinkpad-acpi: rename pci HID constant

[Henrique de Moraes Holschuh]

On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 03:02:46PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sat, 14 Jul 2007, Matthew Garrett wrote:
> > > On Sat, Jul 14, 2007 at 11:12:04AM -0300, Henrique de Moraes Holschuh wrote:
> > > > -	 .hid = IBM_PCI_HID,
> > > > +	/* THIS ONE MUST NEVER BE USED FOR DRIVER AUTOLOADING.
> > > 
> > > Some rationale here would be good. There are no known devices where 
> > > loading ibm-acpi is harmful.
> > 
> > It is completely and utterly useless to autoload based on this.  You would
> > try to autoload it on every machine with a PCI root bridge, which is NOT a
> > bright idea at all.
> 
> I meant the IBM0068 device. That doesn't appear to be used anywhere 
> other than Thinkpads.

Oh, you CAN use the IBM0068 device to autoload.  I am not really sure
nothing but ThinkPads use it, and I already have other autoload hooks (based
on DMI) anyway, but it can be used as an autoload hint, yes.

But the comment about not using a HID for driver autoloading is for the
PCI_ROOT_HID_STRING only.  Is it in a confusing place on the source code, or
somesuch?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: ACPI: thinkpad-acpi: rename pci HID constant

[Matthew Garrett]

On Sun, Jul 15, 2007 at 06:18:21PM -0300, Henrique de Moraes Holschuh wrote:

> Oh, you CAN use the IBM0068 device to autoload.  I am not really sure
> nothing but ThinkPads use it, and I already have other autoload hooks (based
> on DMI) anyway, but it can be used as an autoload hint, yes.
> 
> But the comment about not using a HID for driver autoloading is for the
> PCI_ROOT_HID_STRING only.  Is it in a confusing place on the source code, or
> somesuch?

Sorry, I managed to misread the second hunk of the patch as defining 
PCI_ROOT_HID_STRING as IBM0068 - I'm utterly wrong here, please ignore 
me :)

-- 
Matthew Garrett | mjg59@srcf.ucam.org

pci-ids: add Lenovo PCI vendor ID

[Henrique de Moraes Holschuh]

thinkpad-acpi wants to differentiate IBM from Lenovo ThinkPads, and the PCI
IDs are the best way to go about it for quirk tables and so on.  Add the
missing Lenovo PCI ID to pci_ids.h.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
Cc: Jeff Garzik <jeff-o2qLIJkoznsdnm+yROfE0A@public.gmane.org>
---
 include/linux/pci_ids.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 5b1c999..b5f54ca 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2067,6 +2067,8 @@
 #define PCI_DEVICE_ID_ALTIMA_AC9100	0x03ea
 #define PCI_DEVICE_ID_ALTIMA_AC1003	0x03eb
 
+#define PCI_VENDOR_ID_LENOVO		0x17aa
+
 #define PCI_VENDOR_ID_ARECA		0x17d3
 #define PCI_DEVICE_ID_ARECA_1110	0x1110
 #define PCI_DEVICE_ID_ARECA_1120	0x1120
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: pci-ids: add Lenovo PCI vendor ID

[Jeff Garzik]

Henrique de Moraes Holschuh wrote:
> thinkpad-acpi wants to differentiate IBM from Lenovo ThinkPads, and the PCI
> IDs are the best way to go about it for quirk tables and so on.  Add the
> missing Lenovo PCI ID to pci_ids.h.
> 
> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> Cc: Jeff Garzik <jeff@garzik.org>
> ---
>  include/linux/pci_ids.h |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 5b1c999..b5f54ca 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2067,6 +2067,8 @@
>  #define PCI_DEVICE_ID_ALTIMA_AC9100	0x03ea
>  #define PCI_DEVICE_ID_ALTIMA_AC1003	0x03eb
>  
> +#define PCI_VENDOR_ID_LENOVO		0x17aa
> +
>  #define PCI_VENDOR_ID_ARECA		0x17d3
>  #define PCI_DEVICE_ID_ARECA_1110	0x1110

Not sure why I'm CC'd :)  But of course I have an opinion :)  Usually we 
don't add these IDs until a driver is actually using them.  Just add it 
in the patch that starts using it in thinkpad-acpi.

	Jeff

Re: pci-ids: add Lenovo PCI vendor ID

[Henrique de Moraes Holschuh]

On Sun, 15 Jul 2007, Jeff Garzik wrote:
> Henrique de Moraes Holschuh wrote:
>> thinkpad-acpi wants to differentiate IBM from Lenovo ThinkPads, and the 
>> PCI
>> IDs are the best way to go about it for quirk tables and so on.  Add the
>> missing Lenovo PCI ID to pci_ids.h.
>> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
>> Cc: Jeff Garzik <jeff@garzik.org>
>> ---
>>  include/linux/pci_ids.h |    2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
>> index 5b1c999..b5f54ca 100644
>> --- a/include/linux/pci_ids.h
>> +++ b/include/linux/pci_ids.h
>> @@ -2067,6 +2067,8 @@
>>  #define PCI_DEVICE_ID_ALTIMA_AC9100	0x03ea
>>  #define PCI_DEVICE_ID_ALTIMA_AC1003	0x03eb
>>  +#define PCI_VENDOR_ID_LENOVO		0x17aa
>> +
>>  #define PCI_VENDOR_ID_ARECA		0x17d3
>>  #define PCI_DEVICE_ID_ARECA_1110	0x1110
>
> Not sure why I'm CC'd :)  But of course I have an opinion :)  Usually we 
> don't add these IDs until a driver is actually using them.  Just add it in 
> the patch that starts using it in thinkpad-acpi.

Very well.  I don't usually merge stuff that goes to different subsystems,
but since you implicitly ACK'd it... :-)

I will merge this patch with the next one in the series :)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

ACPI: thinkpad-acpi: store ThinkPad model information

[Henrique de Moraes Holschuh]

Keep note of ThinkPad model, BIOS and EC firmware information, and log it
on startup.  Makes for far more readable code in places, too.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
---
 drivers/misc/thinkpad_acpi.c |   98 ++++++++++++++++++++++++++++++------------
 drivers/misc/thinkpad_acpi.h |   17 ++++++-
 2 files changed, 85 insertions(+), 30 deletions(-)

diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 44aa8c9..99500af 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -717,9 +717,19 @@ static int __init thinkpad_acpi_driver_init(struct ibm_init_struct *iibm)
 	printk(IBM_INFO "%s v%s\n", IBM_DESC, IBM_VERSION);
 	printk(IBM_INFO "%s\n", IBM_URL);
 
-	if (ibm_thinkpad_ec_found)
-		printk(IBM_INFO "ThinkPad EC firmware %s\n",
-		       ibm_thinkpad_ec_found);
+	printk(IBM_INFO "ThinkPad BIOS %s, EC %s\n",
+		(thinkpad_id.bios_version_str) ?
+			thinkpad_id.bios_version_str : "unknown",
+		(thinkpad_id.ec_version_str) ?
+			thinkpad_id.ec_version_str : "unknown");
+
+	if (thinkpad_id.vendor && thinkpad_id.model_str)
+		printk(IBM_INFO "%s %s\n",
+			(thinkpad_id.vendor == PCI_VENDOR_ID_IBM) ?
+				"IBM" : ((thinkpad_id.vendor ==
+						PCI_VENDOR_ID_LENOVO) ?
+					"Lenovo" : "Unknown vendor"),
+			thinkpad_id.model_str);
 
 	return 0;
 }
@@ -2648,7 +2658,7 @@ static int __init thermal_init(struct ibm_init_struct *iibm)
 
 	acpi_tmp7 = acpi_evalf(ec_handle, NULL, "TMP7", "qv");
 
-	if (ibm_thinkpad_ec_found && experimental) {
+	if (thinkpad_id.ec_model && experimental) {
 		/*
 		 * Direct EC access mode: sensors at registers
 		 * 0x78-0x7F, 0xC0-0xC7.  Registers return 0x00 for
@@ -3532,20 +3542,19 @@ static int __init fan_init(struct ibm_init_struct *iibm)
 			 * Enable for TP-1Y (T43), TP-78 (R51e),
 			 * TP-76 (R52), TP-70 (T43, R52), which are known
 			 * to be buggy. */
-			if (fan_control_initial_status == 0x07 &&
-			    ibm_thinkpad_ec_found &&
-			    ((ibm_thinkpad_ec_found[0] == '1' &&
-			      ibm_thinkpad_ec_found[1] == 'Y') ||
-			     (ibm_thinkpad_ec_found[0] == '7' &&
-			      (ibm_thinkpad_ec_found[1] == '6' ||
-			       ibm_thinkpad_ec_found[1] == '8' ||
-			       ibm_thinkpad_ec_found[1] == '0'))
-			    )) {
-				printk(IBM_NOTICE
-				       "fan_init: initial fan status is "
-				       "unknown, assuming it is in auto "
-				       "mode\n");
-				tp_features.fan_ctrl_status_undef = 1;
+			if (fan_control_initial_status == 0x07) {
+				switch (thinkpad_id.ec_model) {
+				case 0x5931: /* TP-1Y */
+				case 0x3837: /* TP-78 */
+				case 0x3637: /* TP-76 */
+				case 0x3037: /* TP-70 */
+					printk(IBM_NOTICE
+					       "fan_init: initial fan status is "
+					       "unknown, assuming it is in auto "
+					       "mode\n");
+					tp_features.fan_ctrl_status_undef = 1;
+					;;
+				}
 			}
 		} else {
 			printk(IBM_ERR
@@ -4279,13 +4288,30 @@ static void ibm_exit(struct ibm_struct *ibm)
 
 /* Probing */
 
-static char *ibm_thinkpad_ec_found;
-
-static char* __init check_dmi_for_ec(void)
+static void __init get_thinkpad_model_data(struct thinkpad_id_data *tp)
 {
 	struct dmi_device *dev = NULL;
 	char ec_fw_string[18];
 
+	if (!tp)
+		return;
+
+	memset(tp, 0, sizeof(*tp));
+
+	if (dmi_name_in_vendors("IBM"))
+		tp->vendor = PCI_VENDOR_ID_IBM;
+	else if (dmi_name_in_vendors("LENOVO"))
+		tp->vendor = PCI_VENDOR_ID_LENOVO;
+	else
+		return;
+
+	tp->bios_version_str = kstrdup(dmi_get_system_info(DMI_BIOS_VERSION),
+					GFP_KERNEL);
+	if (!tp->bios_version_str)
+		return;
+	tp->bios_model = tp->bios_version_str[0]
+			 | (tp->bios_version_str[1] << 8);
+
 	/*
 	 * ThinkPad T23 or newer, A31 or newer, R50e or newer,
 	 * X32 or newer, all Z series;  Some models must have an
@@ -4299,10 +4325,20 @@ static char* __init check_dmi_for_ec(void)
 			   ec_fw_string) == 1) {
 			ec_fw_string[sizeof(ec_fw_string) - 1] = 0;
 			ec_fw_string[strcspn(ec_fw_string, " ]")] = 0;
-			return kstrdup(ec_fw_string, GFP_KERNEL);
+
+			tp->ec_version_str = kstrdup(ec_fw_string, GFP_KERNEL);
+			tp->ec_model = ec_fw_string[0]
+					| (ec_fw_string[1] << 8);
+			break;
 		}
 	}
-	return NULL;
+
+	tp->model_str = kstrdup(dmi_get_system_info(DMI_PRODUCT_VERSION),
+					GFP_KERNEL);
+	if (strnicmp(tp->model_str, "ThinkPad", 8) != 0) {
+		kfree(tp->model_str);
+		tp->model_str = NULL;
+	}
 }
 
 static int __init probe_for_thinkpad(void)
@@ -4316,7 +4352,7 @@ static int __init probe_for_thinkpad(void)
 	 * Non-ancient models have better DMI tagging, but very old models
 	 * don't.
 	 */
-	is_thinkpad = dmi_name_in_vendors("ThinkPad");
+	is_thinkpad = (thinkpad_id.model_str != NULL);
 
 	/* ec is required because many other handles are relative to it */
 	IBM_ACPIHANDLE_INIT(ec);
@@ -4332,7 +4368,7 @@ static int __init probe_for_thinkpad(void)
 	 * false positives a damn great deal
 	 */
 	if (!is_thinkpad)
-		is_thinkpad = dmi_name_in_vendors("IBM");
+		is_thinkpad = (thinkpad_id.vendor == PCI_VENDOR_ID_IBM);
 
 	if (!is_thinkpad && !force_load)
 		return -ENODEV;
@@ -4475,12 +4511,16 @@ static int __init thinkpad_acpi_module_init(void)
 	int ret, i;
 
 	/* Driver-level probe */
+
+	get_thinkpad_model_data(&thinkpad_id);
 	ret = probe_for_thinkpad();
-	if (ret)
+	if (ret) {
+		thinkpad_acpi_module_exit();
 		return ret;
+	}
 
 	/* Driver initialization */
-	ibm_thinkpad_ec_found = check_dmi_for_ec();
+
 	IBM_ACPIHANDLE_INIT(ecrd);
 	IBM_ACPIHANDLE_INIT(ecwr);
 
@@ -4590,7 +4630,9 @@ static void thinkpad_acpi_module_exit(void)
 	if (proc_dir)
 		remove_proc_entry(IBM_PROC_DIR, acpi_root_dir);
 
-	kfree(ibm_thinkpad_ec_found);
+	kfree(thinkpad_id.bios_version_str);
+	kfree(thinkpad_id.ec_version_str);
+	kfree(thinkpad_id.model_str);
 }
 
 module_init(thinkpad_acpi_module_init);
diff --git a/drivers/misc/thinkpad_acpi.h b/drivers/misc/thinkpad_acpi.h
index fee0421..09b2282 100644
--- a/drivers/misc/thinkpad_acpi.h
+++ b/drivers/misc/thinkpad_acpi.h
@@ -175,9 +175,7 @@ static void tpacpi_remove_driver_attributes(struct device_driver *drv);
 static int experimental;
 static u32 dbg_level;
 static int force_load;
-static char *ibm_thinkpad_ec_found;
 
-static char* check_dmi_for_ec(void);
 static int thinkpad_acpi_module_init(void);
 static void thinkpad_acpi_module_exit(void);
 
@@ -244,6 +242,21 @@ static struct {
 	u16 input_device_registered:1;
 } tp_features;
 
+struct thinkpad_id_data {
+	unsigned int vendor;	/* ThinkPad vendor:
+				 * PCI_VENDOR_ID_IBM/PCI_VENDOR_ID_LENOVO */
+
+	char *bios_version_str;	/* Something like 1ZET51WW (1.03z) */
+	char *ec_version_str;	/* Something like 1ZHT51WW-1.04a */
+
+	u16 bios_model;		/* Big Endian, TP-1Y = 0x5931, 0 = unknown */
+	u16 ec_model;
+
+	char *model_str;
+};
+
+static struct thinkpad_id_data thinkpad_id;
+
 static struct list_head tpacpi_all_drivers;
 
 static struct ibm_init_struct ibms_init[];
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: allow use of CMOS NVRAM for brightness control

[Henrique de Moraes Holschuh]

It appears that Lenovo decided to break the EC brightness control interface
in a weird way in their latest BIOSes.  Fortunately, the old CMOS NVRAM
interface works just fine in such BIOSes.

Add a module parameter that allows the user to select which strategy to use
for brightness control: EC, NVRAM, or both.  By default, do both (which is
the way thinkpad-acpi used to work until now) on IBM ThinkPads, and use
NVRAM only on Lenovo ThinkPads.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
---
 Documentation/thinkpad-acpi.txt |    6 ++++
 drivers/misc/Kconfig            |    1 +
 drivers/misc/thinkpad_acpi.c    |   62 +++++++++++++++++++++++++++++++++-----
 drivers/misc/thinkpad_acpi.h    |    7 ++++
 4 files changed, 67 insertions(+), 9 deletions(-)

diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index c670363..c145bcc 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -860,6 +860,12 @@ cannot be controlled.
 The backlight control has eight levels, ranging from 0 to 7.  Some of the
 levels may not be distinct.
 
+There are two interfaces to the firmware for brightness control, EC and CMOS.
+To select which one should be used, use the brightness_mode module parameter:
+brightness_mode=1 selects EC mode, brightness_mode=2 selects CMOS mode,
+brightness_mode=3 selects both EC and CMOS.  The driver tries to autodetect
+which interface to use.
+
 Procfs notes:
 
 	The available commands are:
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 7d92f26..e39cedb 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -141,6 +141,7 @@ config THINKPAD_ACPI
 	depends on X86 && ACPI
 	select BACKLIGHT_CLASS_DEVICE
 	select HWMON
+	select NVRAM
 	---help---
 	  This is a driver for the IBM and Lenovo ThinkPad laptops. It adds
 	  support for Fn-Fx key combinations, Bluetooth control, video
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 99500af..5318eb2 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -2953,9 +2953,22 @@ static int __init brightness_init(struct ibm_init_struct *iibm)
 
 	vdbg_printk(TPACPI_DBG_INIT, "initializing brightness subdriver\n");
 
+	if (!brightness_mode) {
+		if (thinkpad_id.vendor == PCI_VENDOR_ID_LENOVO)
+			brightness_mode = 2;
+		else
+			brightness_mode = 3;
+
+		dbg_printk(TPACPI_DBG_INIT, "selected brightness_mode=%d\n",
+			brightness_mode);
+	}
+
+	if (brightness_mode > 3)
+		return -EINVAL;
+
 	b = brightness_get(NULL);
 	if (b < 0)
-		return b;
+		return 1;
 
 	ibm_backlight_device = backlight_device_register(
 					TPACPI_BACKLIGHT_DEV_NAME, NULL, NULL,
@@ -2991,13 +3004,35 @@ static int brightness_update_status(struct backlight_device *bd)
 				bd->props.brightness : 0);
 }
 
+/*
+ * ThinkPads can read brightness from two places: EC 0x31, or
+ * CMOS NVRAM byte 0x5E, bits 0-3.
+ */
 static int brightness_get(struct backlight_device *bd)
 {
-	u8 level;
-	if (!acpi_ec_read(brightness_offset, &level))
-		return -EIO;
+	u8 lec = 0, lcmos = 0, level = 0;
 
-	level &= 0x7;
+	if (brightness_mode & 1) {
+		if (!acpi_ec_read(brightness_offset, &lec))
+			return -EIO;
+		lec &= 7;
+		level = lec;
+	};
+	if (brightness_mode & 2) {
+		lcmos = (nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS)
+			 & TP_NVRAM_MASK_LEVEL_BRIGHTNESS)
+			>> TP_NVRAM_POS_LEVEL_BRIGHTNESS;
+		level = lcmos;
+	}
+
+	if (brightness_mode == 3 && lec != lcmos) {
+		printk(IBM_ERR
+			"CMOS NVRAM (%u) and EC (%u) do not agree "
+			"on display brightness level\n",
+			(unsigned int) lcmos,
+			(unsigned int) lec);
+		return -EIO;
+	}
 
 	return level;
 }
@@ -3007,14 +3042,20 @@ static int brightness_set(int value)
 	int cmos_cmd, inc, i;
 	int current_value = brightness_get(NULL);
 
-	value &= 7;
+	if (value > 7)
+		return -EINVAL;
 
-	cmos_cmd = value > current_value ? TP_CMOS_BRIGHTNESS_UP : TP_CMOS_BRIGHTNESS_DOWN;
+	cmos_cmd = value > current_value ?
+			TP_CMOS_BRIGHTNESS_UP :
+			TP_CMOS_BRIGHTNESS_DOWN;
 	inc = value > current_value ? 1 : -1;
+
 	for (i = current_value; i != value; i += inc) {
-		if (issue_thinkpad_cmos_command(cmos_cmd))
+		if ((brightness_mode & 2) &&
+		    issue_thinkpad_cmos_command(cmos_cmd))
 			return -EIO;
-		if (!acpi_ec_write(brightness_offset, i + inc))
+		if ((brightness_mode & 1) &&
+		    !acpi_ec_write(brightness_offset, i + inc))
 			return -EIO;
 	}
 
@@ -4485,6 +4526,9 @@ module_param(force_load, bool, 0);
 static int fan_control_allowed;
 module_param_named(fan_control, fan_control_allowed, bool, 0);
 
+static int brightness_mode;
+module_param_named(brightness_mode, brightness_mode, int, 0);
+
 #define IBM_PARAM(feature) \
 	module_param_call(feature, set_ibm_param, NULL, NULL, 0)
 
diff --git a/drivers/misc/thinkpad_acpi.h b/drivers/misc/thinkpad_acpi.h
index 09b2282..b7a4a88 100644
--- a/drivers/misc/thinkpad_acpi.h
+++ b/drivers/misc/thinkpad_acpi.h
@@ -32,6 +32,7 @@
 #include <linux/list.h>
 #include <linux/mutex.h>
 
+#include <linux/nvram.h>
 #include <linux/proc_fs.h>
 #include <linux/sysfs.h>
 #include <linux/backlight.h>
@@ -80,6 +81,11 @@
 #define TP_CMOS_BRIGHTNESS_UP	4
 #define TP_CMOS_BRIGHTNESS_DOWN	5
 
+/* ThinkPad CMOS NVRAM constants */
+#define TP_NVRAM_ADDR_BRIGHTNESS       0x5e
+#define TP_NVRAM_MASK_LEVEL_BRIGHTNESS 0x07
+#define TP_NVRAM_POS_LEVEL_BRIGHTNESS 0
+
 #define onoff(status,bit) ((status) & (1 << (bit)) ? "on" : "off")
 #define enabled(status,bit) ((status) & (1 << (bit)) ? "enabled" : "disabled")
 #define strlencmp(a,b) (strncmp((a), (b), strlen(b)))
@@ -323,6 +329,7 @@ static int bluetooth_write(char *buf);
 
 static struct backlight_device *ibm_backlight_device;
 static int brightness_offset = 0x31;
+static int brightness_mode;
 
 static int brightness_init(struct ibm_init_struct *iibm);
 static void brightness_exit(void);
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: react to Lenovo ThinkPad differences in hot key

[Henrique de Moraes Holschuh]

Lenovo ThinkPads have a slightly different key map layout from IBM
ThinkPads (fn+f2 and fn+f3 are swapped).  Knowing which one we are dealing
with, we can properly set a few more hot keys up by default.

Also, export the correct vendor in the input device, as that information
might be useful to userspace.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
---
 Documentation/thinkpad-acpi.txt |   40 ++++++++++----
 drivers/misc/thinkpad_acpi.c    |  109 +++++++++++++++++++++++++++++----------
 2 files changed, 109 insertions(+), 40 deletions(-)

diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index c145bcc..5d827de 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -270,7 +270,8 @@ remapping KEY_UNKNOWN keys.
 The events are available in an input device, with the following id:
 
 	Bus:		BUS_HOST
-	vendor:		0x1014 (PCI_VENDOR_ID_IBM)
+	vendor:		0x1014 (PCI_VENDOR_ID_IBM)  or
+			0x17aa (PCI_VENDOR_ID_LENOVO)
 	product:	0x5054 ("TP")
 	version:	0x4101
 
@@ -290,12 +291,15 @@ ACPI	Scan
 event	code	Key		Notes
 
 0x1001	0x00	FN+F1		-
-0x1002	0x01	FN+F2		-
+0x1002	0x01	FN+F2		IBM: battery (rare)
+				Lenovo: Screen lock
 
-0x1003	0x02	FN+F3		Many models always report this
-				hot key, even with hot keys
+0x1003	0x02	FN+F3		Many IBM models always report
+				this hot key, even with hot keys
 				disabled or with Fn+F3 masked
 				off
+				IBM: screen lock
+				Lenovo: battery
 
 0x1004	0x03	FN+F4		Sleep button (ACPI sleep button
 				semanthics, i.e. sleep-to-RAM).
@@ -313,13 +317,19 @@ event	code	Key		Notes
 				and W-WAN card if left in control
 				of the firmware.  Does not affect
 				the WLAN card.
+				Should be used to turn on/off all
+				radios (bluetooth+W-WAN+WLAN),
+				really.
 
 0x1006	0x05	FN+F6		-
 
 0x1007	0x06	FN+F7		Video output cycle.
 				Do you feel lucky today?
 
-0x1008	0x07	FN+F8		-
+0x1008	0x07	FN+F8		IBM: toggle screen expand
+				Lenovo: configure ultranav
+
+0x1009	0x08	FN+F9		-
 	..	..		..
 0x100B	0x0A	FN+F11		-
 
@@ -338,13 +348,15 @@ event	code	Key		Notes
 0x100F	0x0E	FN+DELETE	-
 
 0x1010	0x0F	FN+HOME		Brightness up.  This key is
-				always handled by the firmware,
-				even when unmasked.  Just leave
-				it alone.
-0x1011	0x10	FN+END		Brightness down. This key is
-				always handled by the firmware,
-				even when unmasked.  Just leave
-				it alone.
+				always handled by the firmware
+				in IBM ThinkPads, even when
+				unmasked.  Just leave it alone.
+				For Lenovo ThinkPads with a new
+				BIOS, it has to be handled either
+				by the ACPI OSI, or by userspace.
+0x1011	0x10	FN+END		Brightness down.  See brightness
+				up for details.
+
 0x1012	0x11	FN+PGUP		Thinklight toggle.  This key is
 				always handled by the firmware,
 				even when unmasked.
@@ -356,9 +368,13 @@ event	code	Key		Notes
 0x1015	0x14	VOLUME UP	Internal mixer volume up. This
 				key is always handled by the
 				firmware, even when unmasked.
+				NOTE: Lenovo seems to be changing
+				this.
 0x1016	0x15	VOLUME DOWN	Internal mixer volume up. This
 				key is always handled by the
 				firmware, even when unmasked.
+				NOTE: Lenovo seems to be changing
+				this.
 0x1017	0x16	MUTE		Mute internal mixer. This
 				key is always handled by the
 				firmware, even when unmasked.
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 5318eb2..f7dc378 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -758,29 +758,7 @@ static u32 hotkey_orig_mask;
 static u32 hotkey_all_mask;
 static u32 hotkey_reserved_mask;
 
-static u16 hotkey_keycode_map[] = {
-	/* Scan Codes 0x00 to 0x0B: ACPI HKEY FN+F1..F12 */
-	KEY_FN_F1,	KEY_FN_F2,	KEY_FN_F3,	KEY_SLEEP,
-	KEY_FN_F5,	KEY_FN_F6,	KEY_FN_F7,	KEY_FN_F8,
-	KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_SUSPEND,
-	/* Scan codes 0x0C to 0x0F: Other ACPI HKEY hot keys */
-	KEY_UNKNOWN,	/* 0x0C: FN+BACKSPACE */
-	KEY_UNKNOWN,	/* 0x0D: FN+INSERT */
-	KEY_UNKNOWN,	/* 0x0E: FN+DELETE */
-	KEY_RESERVED,	/* 0x0F: FN+HOME (brightness up) */
-	/* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */
-	KEY_RESERVED,	/* 0x10: FN+END (brightness down) */
-	KEY_RESERVED,	/* 0x11: FN+PGUP (thinklight toggle) */
-	KEY_UNKNOWN,	/* 0x12: FN+PGDOWN */
-	KEY_ZOOM,	/* 0x13: FN+SPACE (zoom) */
-	KEY_RESERVED,	/* 0x14: VOLUME UP */
-	KEY_RESERVED,	/* 0x15: VOLUME DOWN */
-	KEY_RESERVED,	/* 0x16: MUTE */
-	KEY_VENDOR,	/* 0x17: Thinkpad/AccessIBM/Lenovo */
-	/* (assignments unknown, please report if found) */
-	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
-	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
-};
+static u16 *hotkey_keycode_map;
 
 static struct attribute_set *hotkey_dev_attributes;
 
@@ -939,6 +917,58 @@ static struct attribute *hotkey_mask_attributes[] = {
 
 static int __init hotkey_init(struct ibm_init_struct *iibm)
 {
+
+	static u16 ibm_keycode_map[] __initdata = {
+		/* Scan Codes 0x00 to 0x0B: ACPI HKEY FN+F1..F12 */
+		KEY_FN_F1,	KEY_FN_F2,	KEY_COFFEE,	KEY_SLEEP,
+		KEY_WLAN,	KEY_FN_F6,	KEY_FN_F7,	KEY_FN_F8,
+		KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_SUSPEND,
+		/* Scan codes 0x0C to 0x0F: Other ACPI HKEY hot keys */
+		KEY_UNKNOWN,	/* 0x0C: FN+BACKSPACE */
+		KEY_UNKNOWN,	/* 0x0D: FN+INSERT */
+		KEY_UNKNOWN,	/* 0x0E: FN+DELETE */
+		KEY_RESERVED,	/* 0x0F: FN+HOME (brightness up) */
+		/* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */
+		KEY_RESERVED,	/* 0x10: FN+END (brightness down) */
+		KEY_RESERVED,	/* 0x11: FN+PGUP (thinklight toggle) */
+		KEY_UNKNOWN,	/* 0x12: FN+PGDOWN */
+		KEY_ZOOM,	/* 0x13: FN+SPACE (zoom) */
+		KEY_RESERVED,	/* 0x14: VOLUME UP */
+		KEY_RESERVED,	/* 0x15: VOLUME DOWN */
+		KEY_RESERVED,	/* 0x16: MUTE */
+		KEY_VENDOR,	/* 0x17: Thinkpad/AccessIBM/Lenovo */
+		/* (assignments unknown, please report if found) */
+		KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
+		KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
+	};
+	static u16 lenovo_keycode_map[] __initdata = {
+		/* Scan Codes 0x00 to 0x0B: ACPI HKEY FN+F1..F12 */
+		KEY_FN_F1,	KEY_COFFEE,	KEY_BATTERY,	KEY_SLEEP,
+		KEY_WLAN,	KEY_FN_F6,	KEY_FN_F7,	KEY_FN_F8,
+		KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_SUSPEND,
+		/* Scan codes 0x0C to 0x0F: Other ACPI HKEY hot keys */
+		KEY_UNKNOWN,	/* 0x0C: FN+BACKSPACE */
+		KEY_UNKNOWN,	/* 0x0D: FN+INSERT */
+		KEY_UNKNOWN,	/* 0x0E: FN+DELETE */
+		KEY_BRIGHTNESSUP,	/* 0x0F: FN+HOME (brightness up) */
+		/* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */
+		KEY_BRIGHTNESSDOWN,	/* 0x10: FN+END (brightness down) */
+		KEY_RESERVED,	/* 0x11: FN+PGUP (thinklight toggle) */
+		KEY_UNKNOWN,	/* 0x12: FN+PGDOWN */
+		KEY_ZOOM,	/* 0x13: FN+SPACE (zoom) */
+		KEY_RESERVED,	/* 0x14: VOLUME UP */
+		KEY_RESERVED,	/* 0x15: VOLUME DOWN */
+		KEY_RESERVED,	/* 0x16: MUTE */
+		KEY_VENDOR,	/* 0x17: Thinkpad/AccessIBM/Lenovo */
+		/* (assignments unknown, please report if found) */
+		KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
+		KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
+	};
+
+#define TPACPI_HOTKEY_MAP_LEN		ARRAY_SIZE(ibm_keycode_map)
+#define TPACPI_HOTKEY_MAP_SIZE		sizeof(ibm_keycode_map)
+#define TPACPI_HOTKEY_MAP_TYPESIZE	sizeof(ibm_keycode_map[0])
+
 	int res, i;
 	int status;
 
@@ -1003,6 +1033,27 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
 		if (res)
 			return res;
 
+		/* Set up key map */
+
+		hotkey_keycode_map = kmalloc(TPACPI_HOTKEY_MAP_SIZE,
+						GFP_KERNEL);
+		if (!hotkey_keycode_map) {
+			printk(IBM_ERR "failed to allocate memory for key map\n");
+			return -ENOMEM;
+		}
+
+		if (thinkpad_id.vendor == PCI_VENDOR_ID_LENOVO) {
+			dbg_printk(TPACPI_DBG_INIT,
+				   "using Lenovo default hot key map\n");
+			memcpy(hotkey_keycode_map, &lenovo_keycode_map,
+				TPACPI_HOTKEY_MAP_SIZE);
+		} else {
+			dbg_printk(TPACPI_DBG_INIT,
+				   "using IBM default hot key map\n");
+			memcpy(hotkey_keycode_map, &ibm_keycode_map,
+				TPACPI_HOTKEY_MAP_SIZE);
+		}
+
 #ifndef CONFIG_THINKPAD_ACPI_INPUT_ENABLED
 		for (i = 0; i < 12; i++)
 			hotkey_keycode_map[i] = KEY_UNKNOWN;
@@ -1011,10 +1062,10 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
 		set_bit(EV_KEY, tpacpi_inputdev->evbit);
 		set_bit(EV_MSC, tpacpi_inputdev->evbit);
 		set_bit(MSC_SCAN, tpacpi_inputdev->mscbit);
-		tpacpi_inputdev->keycodesize = sizeof(hotkey_keycode_map[0]);
-		tpacpi_inputdev->keycodemax = ARRAY_SIZE(hotkey_keycode_map);
-		tpacpi_inputdev->keycode = &hotkey_keycode_map;
-		for (i = 0; i < ARRAY_SIZE(hotkey_keycode_map); i++) {
+		tpacpi_inputdev->keycodesize = TPACPI_HOTKEY_MAP_TYPESIZE;
+		tpacpi_inputdev->keycodemax = TPACPI_HOTKEY_MAP_LEN;
+		tpacpi_inputdev->keycode = hotkey_keycode_map;
+		for (i = 0; i < TPACPI_HOTKEY_MAP_LEN; i++) {
 			if (hotkey_keycode_map[i] != KEY_RESERVED) {
 				set_bit(hotkey_keycode_map[i],
 					tpacpi_inputdev->keybit);
@@ -4618,7 +4669,9 @@ static int __init thinkpad_acpi_module_init(void)
 		tpacpi_inputdev->name = "ThinkPad Extra Buttons";
 		tpacpi_inputdev->phys = IBM_DRVR_NAME "/input0";
 		tpacpi_inputdev->id.bustype = BUS_HOST;
-		tpacpi_inputdev->id.vendor = TPACPI_HKEY_INPUT_VENDOR;
+		tpacpi_inputdev->id.vendor = (thinkpad_id.vendor) ?
+						thinkpad_id.vendor :
+						PCI_VENDOR_ID_IBM;
 		tpacpi_inputdev->id.product = TPACPI_HKEY_INPUT_PRODUCT;
 		tpacpi_inputdev->id.version = TPACPI_HKEY_INPUT_VERSION;
 	}
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: ACPI: thinkpad-acpi: react to Lenovo ThinkPad differences in hot key

[Matthew Garrett]

On Sat, Jul 14, 2007 at 11:12:09AM -0300, Henrique de Moraes Holschuh wrote:

Ah, I see this one fixes some of my comments. However:

> +		KEY_RESERVED,	/* 0x0F: FN+HOME (brightness up) */
> +		/* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */
> +		KEY_RESERVED,	/* 0x10: FN+END (brightness down) */

> +		KEY_BRIGHTNESSUP,	/* 0x0F: FN+HOME (brightness up) */
> +		/* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */
> +		KEY_BRIGHTNESSDOWN,	/* 0x10: FN+END (brightness down) */

Why this difference?
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: ACPI: thinkpad-acpi: react to Lenovo ThinkPad differences in hot key

[Henrique de Moraes Holschuh]

Hi Matthew!

On Sat, 14 Jul 2007, Matthew Garrett wrote:

> On Sat, Jul 14, 2007 at 11:12:09AM -0300, Henrique de Moraes Holschuh wrote:
> 
> Ah, I see this one fixes some of my comments. However:
> 
> > +		KEY_RESERVED,	/* 0x0F: FN+HOME (brightness up) */
> > +		/* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */
> > +		KEY_RESERVED,	/* 0x10: FN+END (brightness down) */
> 
> > +		KEY_BRIGHTNESSUP,	/* 0x0F: FN+HOME (brightness up) */
> > +		/* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */
> > +		KEY_BRIGHTNESSDOWN,	/* 0x10: FN+END (brightness down) */
> 
> Why this difference?

Brightness events are handled in firmware (and no, you cannot make the
firmware NOT handle it) in IBM thinkpads.  Lenovo thinkpads seem to be
moving it to userspace, so you have to generate the events and actively
handle them in the ACPI OSI or in userspace.

I generate events *only* for stuff that needs active handling by default.
Since the hotkey mask cannot really be trusted to filter out events (unless
I start filtering it in the driver *as well*... might be a good idea), I
don't add the passive keys to the keymap.

Regardless, userspace *will* have to take some action to enable the hotkeys
that are to only be used for passive monitoring.  Right now this means
enabling them in the mask, and remapping the key map.  If this is that a big
problem, I can add extra driver filtering, and make it only "enable it in
the mask".

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: ACPI: thinkpad-acpi: react to Lenovo ThinkPad differences in hot key

[Matthew Garrett]

On Sun, Jul 15, 2007 at 02:59:22PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 14 Jul 2007, Matthew Garrett wrote:
> 
> > On Sat, Jul 14, 2007 at 11:12:09AM -0300, Henrique de Moraes Holschuh wrote:
> > 
> > Ah, I see this one fixes some of my comments. However:
> > 
> > > +		KEY_RESERVED,	/* 0x0F: FN+HOME (brightness up) */
> > > +		/* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */
> > > +		KEY_RESERVED,	/* 0x10: FN+END (brightness down) */
> > 
> > > +		KEY_BRIGHTNESSUP,	/* 0x0F: FN+HOME (brightness up) */
> > > +		/* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */
> > > +		KEY_BRIGHTNESSDOWN,	/* 0x10: FN+END (brightness down) */
> > 
> > Why this difference?
> 
> Brightness events are handled in firmware (and no, you cannot make the
> firmware NOT handle it) in IBM thinkpads.  Lenovo thinkpads seem to be
> moving it to userspace, so you have to generate the events and actively
> handle them in the ACPI OSI or in userspace.

I believe that this is dependent on the BIOS version, not whether the 
distinction is Lenovo/IBM.

> Regardless, userspace *will* have to take some action to enable the hotkeys
> that are to only be used for passive monitoring.  Right now this means
> enabling them in the mask, and remapping the key map.  If this is that a big
> problem, I can add extra driver filtering, and make it only "enable it in
> the mask".

HAL already has a flag indicating whether applications should respond to 
brightness keys actively or passively. Life would be significantly 
easier if they're mapped by default, since the alternative is that 
everyone will just map them anyway.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: ACPI: thinkpad-acpi: react to Lenovo ThinkPad differences in hot key

[Henrique de Moraes Holschuh]

Hi Matthew!

On Sun, 15 Jul 2007, Matthew Garrett wrote:

> On Sun, Jul 15, 2007 at 02:59:22PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sat, 14 Jul 2007, Matthew Garrett wrote:
> > 
> > > On Sat, Jul 14, 2007 at 11:12:09AM -0300, Henrique de Moraes Holschuh wrote:
> > > 
> > > Ah, I see this one fixes some of my comments. However:
> > > 
> > > > +		KEY_RESERVED,	/* 0x0F: FN+HOME (brightness up) */
> > > > +		/* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */
> > > > +		KEY_RESERVED,	/* 0x10: FN+END (brightness down) */
> > > 
> > > > +		KEY_BRIGHTNESSUP,	/* 0x0F: FN+HOME (brightness up) */
> > > > +		/* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */
> > > > +		KEY_BRIGHTNESSDOWN,	/* 0x10: FN+END (brightness down) */
> > > 
> > > Why this difference?
> > 
> > Brightness events are handled in firmware (and no, you cannot make the
> > firmware NOT handle it) in IBM thinkpads.  Lenovo thinkpads seem to be
> > moving it to userspace, so you have to generate the events and actively
> > handle them in the ACPI OSI or in userspace.
> 
> I believe that this is dependent on the BIOS version, not whether the 
> distinction is Lenovo/IBM.

Let's just say that IBM kept a certain behaviour consistent for all BIOS
versions, and Lenovo is not following that behaviour.

It might be considered a BIOS version thing, where all IBM-release BIOSES
behave in one way, and most Lenovo ones behave in another way.

But unless someone will start tracking the required information for me in
thinkwiki or somesuch, I will only support the latest versions of a ThinkPad
BIOS as a rule.  IBM and Lenovo BIOS updates fix a damn big lot of problems
quite often.  It is not a good idea to use outdated ones, especially the EC
firmware, anyway.

> > Regardless, userspace *will* have to take some action to enable the hotkeys
> > that are to only be used for passive monitoring.  Right now this means
> > enabling them in the mask, and remapping the key map.  If this is that a big
> > problem, I can add extra driver filtering, and make it only "enable it in
> > the mask".
> 
> HAL already has a flag indicating whether applications should respond to 
> brightness keys actively or passively. Life would be significantly 
> easier if they're mapped by default, since the alternative is that 
> everyone will just map them anyway.

Life would be significantly easier if I could convey that information in the
kernel.  Since I cannot, I effectively consider these keys to be "defective"
as far as the regular input device events are supposed to mean, and I don't
generate events for them.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: ACPI: thinkpad-acpi: react to Lenovo ThinkPad differences in hot key

[Matthew Garrett]

On Sun, Jul 15, 2007 at 05:17:12PM -0300, Henrique de Moraes Holschuh wrote:

> Life would be significantly easier if I could convey that information in the
> kernel.  Since I cannot, I effectively consider these keys to be "defective"
> as far as the regular input device events are supposed to mean, and I don't
> generate events for them.

Any userspace application that can do anything with brightness keys 
needs to know how to speak to that specific hardware /anyway/ - on some 
machines that may be calling a userspace application, on others using an 
interface in /sys/class/backlight, on others calling out to X. There's 
no way to automatically make that decision, so it's fine to insist that 
they also take into account whether it's active or passive.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: make sure DSDT TMPx readings don't return +128

[Henrique de Moraes Holschuh]

We get +128 instead of -128 from the DSDT TMPx methods, due to errors when
converting a EC byte return that is a s8 to an ACPI handler return that is
an int.

Fix it once and for all, by clamping acceptable temperature readings from
DSDT TMPx so that anything outside the [-127,+127] range is converted to
TP_EC_THERMAL_TMP_NA (-128).

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
Cc: Michael Olbrich <michael.olbrich-hi6Y0CQ0nG0@public.gmane.org>
---
 drivers/misc/thinkpad_acpi.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index f7dc378..edae74f 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -2853,6 +2853,8 @@ static int thermal_get_sensor(int idx, s32 *value)
 			snprintf(tmpi, sizeof(tmpi), "TMP%c", '0' + idx);
 			if (!acpi_evalf(ec_handle, &t, tmpi, "d"))
 				return -EIO;
+			if (t > 127 || t < -127)
+				t = TP_EC_THERMAL_TMP_NA;
 			*value = t * 1000;
 			return 0;
 		}
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: make EC-based thermal readings non-experimental

[Henrique de Moraes Holschuh]

Reading the 16 thermal sensors directly from the EC has been stable for
about one year, in all supported ThinkPad models.  Remove its
"experimental" label.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
---
 Documentation/thinkpad-acpi.txt |   18 +++++-------------
 drivers/misc/thinkpad_acpi.c    |    2 +-
 2 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index 5d827de..3eb949e 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -710,23 +710,15 @@ Temperature sensors
 procfs: /proc/acpi/ibm/thermal
 sysfs device attributes: (hwmon) temp*_input
 
-Most ThinkPads include six or more separate temperature sensors but
-only expose the CPU temperature through the standard ACPI methods.
-This feature shows readings from up to eight different sensors on older
-ThinkPads, and it has experimental support for up to sixteen different
-sensors on newer ThinkPads.
-
-EXPERIMENTAL: The 16-sensors feature is marked EXPERIMENTAL because the
-implementation directly accesses hardware registers and may not work as
-expected. USE WITH CAUTION! To use this feature, you need to supply the
-experimental=1 parameter when loading the module.  When EXPERIMENTAL
-mode is enabled, reading the first 8 sensors on newer ThinkPads will
-also use an new experimental thermal sensor access mode.
+Most ThinkPads include six or more separate temperature sensors but only
+expose the CPU temperature through the standard ACPI methods.  This
+feature shows readings from up to eight different sensors on older
+ThinkPads, and up to sixteen different sensors on newer ThinkPads.
 
 For example, on the X40, a typical output may be:
 temperatures:   42 42 45 41 36 -128 33 -128
 
-EXPERIMENTAL: On the T43/p, a typical output may be:
+On the T43/p, a typical output may be:
 temperatures:   48 48 36 52 38 -128 31 -128 48 52 48 -128 -128 -128 -128 -128
 
 The mapping of thermal sensors to physical locations varies depending on
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index edae74f..2a26941 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -2709,7 +2709,7 @@ static int __init thermal_init(struct ibm_init_struct *iibm)
 
 	acpi_tmp7 = acpi_evalf(ec_handle, NULL, "TMP7", "qv");
 
-	if (thinkpad_id.ec_model && experimental) {
+	if (thinkpad_id.ec_model) {
 		/*
 		 * Direct EC access mode: sensors at registers
 		 * 0x78-0x7F, 0xC0-0xC7.  Registers return 0x00 for
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: bump up version to 0.15

[Henrique de Moraes Holschuh]

Name it thinkpad-acpi version 0.15.

Signed-off-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
---
 Documentation/thinkpad-acpi.txt |    8 ++++----
 drivers/misc/thinkpad_acpi.c    |    2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index 3eb949e..6711fbc 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -1,11 +1,11 @@
 		     ThinkPad ACPI Extras Driver
 
-                            Version 0.14
-                          April 21st, 2007
+                            Version 0.15
+                           July 1st, 2007
 
                Borislav Deianov <borislav-iA+eEnwkJgzk1uMJSBkQmQ@public.gmane.org>
-	     Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
-		      http://ibm-acpi.sf.net/
+             Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org>
+                      http://ibm-acpi.sf.net/
 
 
 This is a Linux driver for the IBM and Lenovo ThinkPad laptops. It
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 2a26941..a8c228a 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -21,7 +21,7 @@
  *  02110-1301, USA.
  */
 
-#define IBM_VERSION "0.14"
+#define IBM_VERSION "0.15"
 #define TPACPI_SYSFS_VERSION 0x010000
 
 /*
-- 
1.5.2.1


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: [GIT PULL] thinkpad-acpi queue for 2.6.23 (v2)

[Henrique de Moraes Holschuh]

Len,

I forgot to tell git send-email to number the patches.  Sorry about that.

The shortlog has the correct patch order listed, and there is also the git
branch.

Still, if you'd rather I post the batch again with the proper patch ordering
in the subject this time, just say so.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

ACPI: thinkpad-acpi: update CMOS commands documentation

[Henrique de Moraes Holschuh]

The CMOS set of commands is often just used to keep the CMOS NVRAM in sync
with whatever the ACPI BIOS has been doing in modern ThinkPads.  In older
ThinkPads, it actually carried out real actions.  Document this.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
---
 Documentation/thinkpad-acpi.txt |   35 +++++++++++++++++++++--------------
 1 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index 7a06a27..bd00d14 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -464,27 +464,34 @@ CMOS control
 procfs: /proc/acpi/ibm/cmos
 sysfs device attribute: cmos_command
 
-This feature is used internally by the ACPI firmware to control the
-ThinkLight on most newer ThinkPad models. It may also control LCD
-brightness, sounds volume and more, but only on some models.
+This feature is mostly used internally by the ACPI firmware to keep the legacy
+CMOS NVRAM bits in sync with the current machine state, and to record this
+state so that the ThinkPad will retain such settings across reboots.
+
+Some of these commands actually perform actions in some ThinkPad models, but
+this is expected to disappear more and more in newer models.  As an example, in
+a T43 and in a X40, commands 12 and 13 still control the ThinkLight state for
+real, but commands 0 to 2 don't control the mixer anymore (they have been
+phased out) and just update the NVRAM.
 
 The range of valid cmos command numbers is 0 to 21, but not all have an
 effect and the behavior varies from model to model.  Here is the behavior
 on the X40 (tpb is the ThinkPad Buttons utility):
 
-	0 - no effect but tpb reports "Volume down"
-	1 - no effect but tpb reports "Volume up"
-	2 - no effect but tpb reports "Mute on"
-	3 - simulate pressing the "Access IBM" button
-	4 - LCD brightness up
-	5 - LCD brightness down
-	11 - toggle screen expansion
-	12 - ThinkLight on
-	13 - ThinkLight off
-	14 - no effect but tpb reports ThinkLight status change
+	0 - Related to "Volume down" key press
+	1 - Related to "Volume up" key press
+	2 - Related to "Mute on" key press
+	3 - Related to "Access IBM" key press
+	4 - Related to "LCD brightness up" key pess
+	5 - Related to "LCD brightness down" key press
+	11 - Related to "toggle screen expansion" key press/function
+	12 - Related to "ThinkLight on"
+	13 - Related to "ThinkLight off"
+	14 - Related to "ThinkLight" key press (toggle thinklight)
 
 The cmos command interface is prone to firmware split-brain problems, as
-in newer ThinkPads it is just a compatibility layer.
+in newer ThinkPads it is just a compatibility layer.  Do not use it, it is
+exported just as a debug tool.
 
 LED control -- /proc/acpi/ibm/led
 ---------------------------------
-- 
1.5.2.1

ACPI: thinkpad-acpi: make the input event mode the default

[Henrique de Moraes Holschuh]

Make the input layer the default way to deal with thinkpad-acpi hot keys,
but add a kernel config option to retain the old way of doing things.

This means we map a lot more keys to useful stuff by default, and also that
we enable hot key handling by default on driver load (like Windows does).

The documentation for proper use of this resource is also updated.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Richard Hughes <hughsient@gmail.com>
---
 Documentation/thinkpad-acpi.txt |   89 ++++++++++++++++++---------------------
 drivers/misc/Kconfig            |   12 +++++
 drivers/misc/thinkpad_acpi.c    |   19 +++++++-
 3 files changed, 69 insertions(+), 51 deletions(-)

diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index 91d0892..5b59cf5 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -155,52 +155,47 @@ Hot keys
 procfs: /proc/acpi/ibm/hotkey
 sysfs device attribute: hotkey_*
 
-Without this driver, only the Fn-F4 key (sleep button) generates an
-ACPI event. With the driver loaded, the hotkey feature enabled and the
-mask set (see below), the various hot keys generate ACPI events in the
+In a ThinkPad, the ACPI HKEY handler is responsible for comunicating
+some important events and also keyboard hot key presses to the operating
+system.  Enabling the hotkey functionality of thinkpad-acpi signals the
+firmware that such a driver is present, and modifies how the ThinkPad
+firmware will behave in many situations.
+
+When the hotkey feature is enabled and the hot key mask is set (see
+below), the various hot keys either generate ACPI events in the
 following format:
 
 	ibm/hotkey HKEY 00000080 0000xxxx
 
-The last four digits vary depending on the key combination pressed.
-All labeled Fn-Fx key combinations generate distinct events. In
-addition, the lid microswitch and some docking station buttons may
-also generate such events.
-
-Hot keys also generate regular keyboard key press/release events through
-the input layer in addition to the ibm/hotkey ACPI events.  The input
-layer support accepts the standard IOCTLs to remap the keycodes assigned
-to each hotkey.
+or events over the input layer.  The input layer support accepts the
+standard IOCTLs to remap the keycodes assigned to each hotkey.
 
 When the input device is open, the driver will suppress any ACPI hot key
 events that get translated into a meaningful input layer event, in order
 to avoid sending duplicate events to userspace.  Hot keys that are
-mapped to KEY_RESERVED are not translated, and will always generate only
-ACPI hot key event, and no input layer events.
-
-The bit mask allows some control over which hot keys generate ACPI
-events. Not all bits in the mask can be modified. Not all bits that can
-be modified do anything. Not all hot keys can be individually controlled
-by the mask. Some models do not support the mask at all. On those
-models, hot keys cannot be controlled individually.
-
-Note that enabling ACPI events for some keys prevents their default
-behavior. For example, if events for Fn-F5 are enabled, that key will no
-longer enable/disable Bluetooth by itself. This can still be done from
-an acpid handler for the ibm/hotkey event.
-
-On some models, even enabling/disabling the entire hot key feature may
-change the way some keys behave (e.g. in a T43, Fn+F4 will generate an
-button/sleep ACPI event if hot keys are disabled, and it will ignore its
-mask when hot keys are enabled, so the key always does something.  On a
-X40, Fn+F4 respects its mask status, but generates the button/sleep ACPI
-event if masked off).
-
-Note also that not all Fn key combinations are supported through
-ACPI. For example, on the X40, the brightness, volume and "Access IBM"
-buttons do not generate ACPI events even with this driver. They *can*
-be used through the "ThinkPad Buttons" utility, see
-http://www.nongnu.org/tpb/
+mapped to KEY_RESERVED in the keymap are not translated, and will always
+generate an ACPI ibm/hotkey HKEY event, and no input layer events.
+
+The hot key bit mask allows some control over which hot keys generate
+events.  If a key is "masked" (bit set to 0 in the mask), the firmware
+will handle it.  If it is "unmasked", it signals the firmware that
+thinkpad-acpi would prefer to handle it, if the firmware would be so
+kind to allow it (and it often doesn't!).
+
+Not all bits in the mask can be modified.  Not all bits that can be
+modified do anything.  Not all hot keys can be individually controlled
+by the mask.  Some models do not support the mask at all, and in those
+models, hot keys cannot be controlled individually.  The behaviour of
+the mask is, therefore, higly dependent on the ThinkPad model.
+
+Note that unmasking some keys prevents their default behavior.  For
+example, if Fn+F5 is unmasked, that key will no longer enable/disable
+Bluetooth by itself.
+
+Note also that not all Fn key combinations are supported through ACPI.
+For example, on the X40, the brightness, volume and "Access IBM" buttons
+do not generate ACPI events even with this driver.  They *can* be used
+through the "ThinkPad Buttons" utility, see http://www.nongnu.org/tpb/
 
 procfs notes:
 
@@ -221,7 +216,7 @@ sysfs notes:
 		key feature status will be restored to this value.
 
 		0: hot keys were disabled
-		1: hot keys were enabled
+		1: hot keys were enabled (unusual)
 
 	hotkey_bios_mask:
 		Returns the hot keys mask when thinkpad-acpi was loaded.
@@ -236,9 +231,10 @@ sysfs notes:
 		1: enables the hot keys feature / feature enabled
 
 	hotkey_mask:
-		bit mask to enable ACPI event generation for each hot
-		key (see above).  Returns the current status of the hot
-		keys mask, and allows one to modify it.
+		bit mask to enable driver-handling and ACPI event
+		generation for each hot key (see above).  Returns the
+		current status of the hot keys mask, and allows one to
+		modify it.
 
 	hotkey_all_mask:
 		bit mask that should enable event reporting for all
@@ -250,8 +246,9 @@ sysfs notes:
 
 	hotkey_recommended_mask:
 		bit mask that should enable event reporting for all
-		supported hot keys, except those which are handled by
-		the firmware.  Echo it to hotkey_mask above, to use.
+		supported hot keys, except those which are always
+		handled by the firmware anyway.  Echo it to
+		hotkey_mask above, to use.
 
 	hotkey_radio_sw:
 		if the ThinkPad has a hardware radio switch, this
@@ -390,10 +387,6 @@ ACPI hotkey event.
 If a key is mapped to anything else, it will only generate legacy
 thinkpad-acpi ACPI hotkey events if nobody has opened the input device.
 
-For userspace backwards-compatibility purposes, the keycode map is
-initially filled with KEY_RESERVED and KEY_UNKNOWN mappings for scan codes
-0x00 to 0x10 (and maybe others).
-
 Non hot-key ACPI HKEY event map:
 0x5001		Lid closed
 0x5002		Lid opened
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 616eee9..7d92f26 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -187,5 +187,17 @@ config THINKPAD_ACPI_BAY
 
 	  If you are not sure, say Y here.
 
+config THINKPAD_ACPI_INPUT_ENABLED
+	bool "Enable input layer support by default"
+	depends on THINKPAD_ACPI
+	default y
+	---help---
+	  Enables hot key handling over the input layer by default.  If unset,
+	  the driver does not enable any hot key handling by default, and also
+	  starts up with a mostly empty keymap.
+
+	  If you are not sure, say Y here.  Say N to retain the deprecated
+	  behavior of ibm-acpi, and thinkpad-acpi for kernels up to 2.6.21.
+
 
 endmenu
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 5c1bea1..c86b228 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -734,9 +734,9 @@ static u32 hotkey_reserved_mask;
 
 static u16 hotkey_keycode_map[] = {
 	/* Scan Codes 0x00 to 0x0B: ACPI HKEY FN+F1..F12 */
-	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
-	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
-	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
+	KEY_FN_F1,	KEY_FN_F2,	KEY_FN_F3,	KEY_SLEEP,
+	KEY_FN_F5,	KEY_FN_F6,	KEY_FN_F7,	KEY_FN_F8,
+	KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_SUSPEND,
 	/* Scan codes 0x0C to 0x0F: Other ACPI HKEY hot keys */
 	KEY_UNKNOWN,	/* 0x0C: FN+BACKSPACE */
 	KEY_UNKNOWN,	/* 0x0D: FN+INSERT */
@@ -977,6 +977,11 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
 		if (res)
 			return res;
 
+#ifndef CONFIG_THINKPAD_ACPI_INPUT_ENABLED
+		for (i = 0; i < 12; i++)
+			hotkey_keycode_map[i] = KEY_UNKNOWN;
+#endif /* ! CONFIG_THINKPAD_ACPI_INPUT_ENABLED */
+
 		set_bit(EV_KEY, tpacpi_inputdev->evbit);
 		set_bit(EV_MSC, tpacpi_inputdev->evbit);
 		set_bit(MSC_SCAN, tpacpi_inputdev->mscbit);
@@ -993,6 +998,14 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
 			}
 		}
 
+#ifdef CONFIG_THINKPAD_ACPI_INPUT_ENABLED
+		dbg_printk(TPACPI_DBG_INIT,
+				"enabling hot key handling\n");
+		res = hotkey_set(1, (hotkey_all_mask & ~hotkey_reserved_mask)
+					| hotkey_orig_mask);
+		if (res)
+			return res;
+#endif /* CONFIG_THINKPAD_ACPI_INPUT_ENABLED */
 	}
 
 	return (tp_features.hotkey)? 0 : 1;
-- 
1.5.2.1

Re: ACPI: thinkpad-acpi: make the input event mode the default

[Matthew Garrett]

On Sat, Jul 14, 2007 at 11:12:00AM -0300, Henrique de Moraes Holschuh wrote:
> -	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> -	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> -	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> +	KEY_FN_F1,	KEY_FN_F2,	KEY_FN_F3,	KEY_SLEEP,
> +	KEY_FN_F5,	KEY_FN_F6,	KEY_FN_F7,	KEY_FN_F8,
> +	KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_SUSPEND,

Again, we have keycodes for most of these and we have the ability to 
make the driver choose the correct one by default. Why make things more 
difficult?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: ACPI: thinkpad-acpi: make the input event mode the default

[Henrique de Moraes Holschuh]

On Sat, 14 Jul 2007, Matthew Garrett wrote:
> On Sat, Jul 14, 2007 at 11:12:00AM -0300, Henrique de Moraes Holschuh wrote:
> > -	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > -	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > -	KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > +	KEY_FN_F1,	KEY_FN_F2,	KEY_FN_F3,	KEY_SLEEP,
> > +	KEY_FN_F5,	KEY_FN_F6,	KEY_FN_F7,	KEY_FN_F8,
> > +	KEY_FN_F9,	KEY_FN_F10,	KEY_FN_F11,	KEY_SUSPEND,
> 
> Again, we have keycodes for most of these and we have the ability to 
> make the driver choose the correct one by default. Why make things more 
> difficult?

Because I only map keys that are marked (silk-screened) on the keys on at
least 90% of the current models.

And I could not find the proper keycode for "switch output video port", yet.

And I could not find the proper keycode for "mess with
mouse/ultranav/pointing device config", either.  Not that this one is marked
in most thinkpads, even if it *does* have this function in almost all of
them.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: ACPI: thinkpad-acpi: make the input event mode the default

[Matthew Garrett]

On Sun, Jul 15, 2007 at 03:05:29PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 14 Jul 2007, Matthew Garrett wrote:
> > Again, we have keycodes for most of these and we have the ability to 
> > make the driver choose the correct one by default. Why make things more 
> > difficult?
> 
> Because I only map keys that are marked (silk-screened) on the keys on at
> least 90% of the current models.

But we're able to differentiate between the models.

> And I could not find the proper keycode for "switch output video port", yet.

Yes, that's a good point. Dmitry? As vendors move towards adopting the 
ACPI video extension and getting the OS to look after this, we could 
really do with a standardised code.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: make the input event mode the default

[Henrique de Moraes Holschuh]

On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 03:05:29PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sat, 14 Jul 2007, Matthew Garrett wrote:
> > > Again, we have keycodes for most of these and we have the ability to 
> > > make the driver choose the correct one by default. Why make things more 
> > > difficult?
> > 
> > Because I only map keys that are marked (silk-screened) on the keys on at
> > least 90% of the current models.
> 
> But we're able to differentiate between the models.

Yes. And I was told to not do it in the kernel when possible, so I will map
by default only what is marked and working on a vast majority.  Otherwise,
I'd need a big quirk db, based on what is silk-screened on the keyboards.

HAL is welcome to remap the keys to whatever it wants, based on
model-specific fdi files.

> > And I could not find the proper keycode for "switch output video port", yet.
> 
> Yes, that's a good point. Dmitry? As vendors move towards adopting the 
> ACPI video extension and getting the OS to look after this, we could 
> really do with a standardised code.

Well, that one I will add as soon as I get it :-)  All thinkpads I know the
keyboard layout have FN+F7 mapped to "switch output video port".  But I have
seen a lot of non-thinkpad notebooks with "set output port to LCD" and "set
output port to vga out" keys as well.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: make the input event mode the default

[Matthew Garrett]

On Sun, Jul 15, 2007 at 05:09:48PM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > But we're able to differentiate between the models.
> 
> Yes. And I was told to not do it in the kernel when possible, so I will map
> by default only what is marked and working on a vast majority.  Otherwise,
> I'd need a big quirk db, based on what is silk-screened on the keyboards.

We already have in-kernel drivers that do this properly, so I'd suspect 
that whoever told you that was wrong.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: make the input event mode the default

[Henrique de Moraes Holschuh]

On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 05:09:48PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > > But we're able to differentiate between the models.
> > 
> > Yes. And I was told to not do it in the kernel when possible, so I will map
> > by default only what is marked and working on a vast majority.  Otherwise,
> > I'd need a big quirk db, based on what is silk-screened on the keyboards.
> 
> We already have in-kernel drivers that do this properly, so I'd suspect 
> that whoever told you that was wrong.

I got tired of being told one way or the other, already.

My position is simple, for now: I am keeping model-specific knowledge on the
driver to the bare minimum needed for correct driver operation.  But I will
add it anytime I fell it is needed to keep correct driver operation.

The different lenovo/ibm keymaps were added because of the mess with the
brightness and volume keys in the latest BIOSes.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: ACPI: thinkpad-acpi: make the input event mode the default

[Matthew Garrett]

On Sun, Jul 15, 2007 at 06:14:21PM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > We already have in-kernel drivers that do this properly, so I'd suspect 
> > that whoever told you that was wrong.
> 
> I got tired of being told one way or the other, already.
> 
> My position is simple, for now: I am keeping model-specific knowledge on the
> driver to the bare minimum needed for correct driver operation.  But I will
> add it anytime I fell it is needed to keep correct driver operation.

Right now, the hotkey functionality of the driver is not terribly useful 
without (bleeding-edge) userspace. This is inconsistent with the 
majority of input drivers which do something broadly sane in that 
situation.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: ACPI: thinkpad-acpi: make the input event mode the default

[Henrique de Moraes Holschuh]

On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 06:14:21PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > > We already have in-kernel drivers that do this properly, so I'd suspect 
> > > that whoever told you that was wrong.
> > 
> > I got tired of being told one way or the other, already.
> > 
> > My position is simple, for now: I am keeping model-specific knowledge on the
> > driver to the bare minimum needed for correct driver operation.  But I will
> > add it anytime I fell it is needed to keep correct driver operation.
> 
> Right now, the hotkey functionality of the driver is not terribly useful 
> without (bleeding-edge) userspace. This is inconsistent with the 
> majority of input drivers which do something broadly sane in that 
> situation.

It works better with non-bleeding-edge userspace the way I did it, as far as
I know. So I'll need some explanations about what I should be doing
differently.

Here's my view on things:

Non-bleeding-edge userspace screws up volume control if I send events.  And
so does bleeding-edge userspace for that matter, AFAIK.

Non-bleeding-edge userspace screws up brightness control if I send events.
Bleeding-edge userspace needs to be told it exists, anyway, to make proper
use of it, and can be told to enable it on the driver while at it.

Non-bleeding-edge userspace that is not broken can remap keys already.
FN+F1 generating KEY_FN_F1 makes a lot more sense to someone which has a
blank FN+F1 key, than it generating "KEY_FOOBAR".

So exactly what should I be changing to make it more useful?  WHAT hot keys
do you want mapped by default, and to which key codes?  And forget the ones
that need passive handling, these are not mapped for a very different
reason.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: ACPI: thinkpad-acpi: make the input event mode the default

[Matthew Garrett]

On Sun, Jul 15, 2007 at 07:08:01PM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > Right now, the hotkey functionality of the driver is not terribly useful 
> > without (bleeding-edge) userspace. This is inconsistent with the 
> > majority of input drivers which do something broadly sane in that 
> > situation.
> 
> It works better with non-bleeding-edge userspace the way I did it, as far as
> I know. So I'll need some explanations about what I should be doing
> differently.
> 
> Here's my view on things:
> 
> Non-bleeding-edge userspace screws up volume control if I send events.  And
> so does bleeding-edge userspace for that matter, AFAIK.

No, it doesn't. It interacts in a way that you may not consider to be 
ideal - the vast majority of our users appear to prefer it to the 
previous behaviour, so it's better than nothing.

> Non-bleeding-edge userspace screws up brightness control if I send events.

No. Nothing will screw up if you send brightness events.

> Bleeding-edge userspace needs to be told it exists, anyway, to make proper
> use of it, and can be told to enable it on the driver while at it.

We've been listening for KEY_BRIGHTNESS* on Thinkpads for over a year. 
It's already implemented and works fine.

> Non-bleeding-edge userspace that is not broken can remap keys already.
> FN+F1 generating KEY_FN_F1 makes a lot more sense to someone which has a
> blank FN+F1 key, than it generating "KEY_FOOBAR".

That's fine. Send KEY_FN_F1 if there's no label.

> So exactly what should I be changing to make it more useful?  WHAT hot keys
> do you want mapped by default, and to which key codes?  And forget the ones
> that need passive handling, these are not mapped for a very different
> reason.

On a machine with a glyph, the driver should generate a keycode 
appropriate for that glyph.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: make the input event mode the default

[Henrique de Moraes Holschuh]

On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 07:08:01PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > > Right now, the hotkey functionality of the driver is not terribly useful 
> > > without (bleeding-edge) userspace. This is inconsistent with the 
> > > majority of input drivers which do something broadly sane in that 
> > > situation.
> > 
> > It works better with non-bleeding-edge userspace the way I did it, as far as
> > I know. So I'll need some explanations about what I should be doing
> > differently.
> > 
> > Here's my view on things:
> > 
> > Non-bleeding-edge userspace screws up volume control if I send events.  And
> > so does bleeding-edge userspace for that matter, AFAIK.
> 
> No, it doesn't. It interacts in a way that you may not consider to be 
> ideal - the vast majority of our users appear to prefer it to the 
> previous behaviour, so it's better than nothing.

I don't go for "better than nothing", when there is a way to have it right
(and there is: an alsa mixer, or an extension to the input layer).

> > Non-bleeding-edge userspace screws up brightness control if I send events.
> 
> No. Nothing will screw up if you send brightness events.

It can, if it feed backs a brightness up order to the kernel, either
through thinkpad-acpi, or through the ACPI video driver at the wrong time
(before the thinkpad firmware did it).  And before you think the firmware
might be doing something sane for a change, I've had reports of more than
half-a-second delay on a X60s without the latest EC between a brightness
change order, and the hardware responding to it.

A bad feedback will either increase brightness once with two writes (waste
of resources, but the user won't notice, and I hope the thinkpad hardware is
not so crappy as to bother the inverter in this case), increase twice, or
cause a loop (got a report, don't know how it happened, but I *do* know the
code has no defense --yet-- against such a loop) that makes it increase the
brightness all the way up or all the way down until you press some other key
that disturbs the loop.

I actually prefer Lenovo's idea of not handling brightness up/down in
firmware anymore, and just reporting the keys...

> > Bleeding-edge userspace needs to be told it exists, anyway, to make proper
> > use of it, and can be told to enable it on the driver while at it.
> 
> We've been listening for KEY_BRIGHTNESS* on Thinkpads for over a year. 
> It's already implemented and works fine.

If everything did it right, I would have never heard of it.  Note that I am
not accusing HAL of breakage, I am talking about *userspace*.  I am *not*
sure if hal is what broke it, and, if it indeed was hal, whether it was new
enough.  I am sure bleeding-edge hal does something sensible for brightness,
and I have no reasons not to believe you that one-year-old hal will do
something wrong, either.  But there is other userspace, AND much older hal.

> > Non-bleeding-edge userspace that is not broken can remap keys already.
> > FN+F1 generating KEY_FN_F1 makes a lot more sense to someone which has a
> > blank FN+F1 key, than it generating "KEY_FOOBAR".
> 
> That's fine. Send KEY_FN_F1 if there's no label.

Isn't that what I am doing right now?  That's why I asked you which key
codes I was missing when you complained about it. I really don't know of
any.

> > So exactly what should I be changing to make it more useful?  WHAT hot keys
> > do you want mapped by default, and to which key codes?  And forget the ones
> > that need passive handling, these are not mapped for a very different
> > reason.
> 
> On a machine with a glyph, the driver should generate a keycode 
> appropriate for that glyph.

It already does so for every key with a glyph that requires active handling
AND which is present on most thinkpads AND for which I could find a sensible
keycode.

Oh, I miss an undock/eject generic device keycode, too.  Can't use EJECTCD
to undock...

Again, what you want me to change in that default key code matrix that is
not a passive-action key?  I aimed to do the best I could according to the
info I have (http://thinkwiki.org/wiki/Default_meanings_of_special_keys).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: ACPI: thinkpad-acpi: make the input event mode the default

[Matthew Garrett]

On Sun, Jul 15, 2007 at 09:12:40PM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > No, it doesn't. It interacts in a way that you may not consider to be 
> > ideal - the vast majority of our users appear to prefer it to the 
> > previous behaviour, so it's better than nothing.
> 
> I don't go for "better than nothing", when there is a way to have it right
> (and there is: an alsa mixer, or an extension to the input layer).

Certainly. Once it's possible to do it the right way, we can do it the 
right way :)

> > No. Nothing will screw up if you send brightness events.
> 
> It can, if it feed backs a brightness up order to the kernel, either
> through thinkpad-acpi, or through the ACPI video driver at the wrong time
> (before the thinkpad firmware did it).  And before you think the firmware
> might be doing something sane for a change, I've had reports of more than
> half-a-second delay on a X60s without the latest EC between a brightness
> change order, and the hardware responding to it.
> 
> A bad feedback will either increase brightness once with two writes (waste
> of resources, but the user won't notice, and I hope the thinkpad hardware is
> not so crappy as to bother the inverter in this case), increase twice, or
> cause a loop (got a report, don't know how it happened, but I *do* know the
> code has no defense --yet-- against such a loop) that makes it increase the
> brightness all the way up or all the way down until you press some other key
> that disturbs the loop.

The only code currently listening for KEY_BRIGHTNESS* on Thinkpads is 
gnome-power-manager, and that uses the Hal information to check whether 
it needs to behave passively or actively and so does the right thing. 
Anything else is either Thinkpad-specific and doesn't listen for 
KEY_BRIGHTNESS or listens for KEY_BRIGHTNESS and doesn't know how to 
control the Thinkpad hardware. As a result, sending KEY_BRIGHTNESS can't 
break any existing software.

> > We've been listening for KEY_BRIGHTNESS* on Thinkpads for over a year. 
> > It's already implemented and works fine.
> 
> If everything did it right, I would have never heard of it.  Note that I am
> not accusing HAL of breakage, I am talking about *userspace*.  I am *not*
> sure if hal is what broke it, and, if it indeed was hal, whether it was new
> enough.  I am sure bleeding-edge hal does something sensible for brightness,
> and I have no reasons not to believe you that one-year-old hal will do
> something wrong, either.  But there is other userspace, AND much older hal.

We had a broken version of hal in a development version of Ubuntu. No 
release version (of Ubuntu or hal) has ever had this bug.

> > That's fine. Send KEY_FN_F1 if there's no label.
> 
> Isn't that what I am doing right now?  That's why I asked you which key
> codes I was missing when you complained about it. I really don't know of
> any.

I hadn't read all the way through the patch series before sending my 
initial mail, so the one that added more keys fixes most of my concerns.

> > On a machine with a glyph, the driver should generate a keycode 
> > appropriate for that glyph.
> 
> It already does so for every key with a glyph that requires active handling
> AND which is present on most thinkpads AND for which I could find a sensible
> keycode.
> 
> Oh, I miss an undock/eject generic device keycode, too.  Can't use EJECTCD
> to undock...
> 
> Again, what you want me to change in that default key code matrix that is
> not a passive-action key?  I aimed to do the best I could according to the
> info I have (http://thinkwiki.org/wiki/Default_meanings_of_special_keys).

Having checked other drivers, it looks like KEY_SWITCHVIDEOMODE is the 
one used for video toggling. If that's not actually how people are using 
it, we need to fix that - if it is, I'd just go for it.

As for the passive keys - I can (with a very high level of certainty) 
assert that there is no existing userspace that will be broken by 
sending the brightness keys. We can quibble over the volume ones, but 
even there the breakage is minimal.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: make the input event mode the default

[Henrique de Moraes Holschuh]

On Mon, 16 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 09:12:40PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > > No, it doesn't. It interacts in a way that you may not consider to be 
> > > ideal - the vast majority of our users appear to prefer it to the 
> > > previous behaviour, so it's better than nothing.
> > 
> > I don't go for "better than nothing", when there is a way to have it right
> > (and there is: an alsa mixer, or an extension to the input layer).
> 
> Certainly. Once it's possible to do it the right way, we can do it the 
> right way :)

I can priorize one thing over another.  HAL guys, please chose which one I
shall work on first (non-zero chance of it getting ready before the merge
window closes):

1. ALSA mixer interface for the thinkpad speakers-and-headphone-out volume
control

2. CMOS NVRAM snooping support for transparent handling of non-acpi-event-
enabled hot keys (i.e. "tpb functionality").  Needed by every thinkpad
before the T43, and apparently, by the R60 for the thinkpad button.

> The only code currently listening for KEY_BRIGHTNESS* on Thinkpads is 
> gnome-power-manager, and that uses the Hal information to check whether 

What about KDE? Doesn't it have any helpers?

> > > We've been listening for KEY_BRIGHTNESS* on Thinkpads for over a year. 
> > > It's already implemented and works fine.
> > 
> > If everything did it right, I would have never heard of it.  Note that I am
> > not accusing HAL of breakage, I am talking about *userspace*.  I am *not*
> > sure if hal is what broke it, and, if it indeed was hal, whether it was new
> > enough.  I am sure bleeding-edge hal does something sensible for brightness,
> > and I have no reasons not to believe you that one-year-old hal will do
> > something wrong, either.  But there is other userspace, AND much older hal.
> 
> We had a broken version of hal in a development version of Ubuntu. No 
> release version (of Ubuntu or hal) has ever had this bug.

What about other distros?  Ubuntu isn't the world, anymore than HAL is all
that matters in userspace.

A broken version of HAL might explain the bug report, or it might not. I'd
have to track it down, and frankly, I'd rather spend precious kernel hacking
time with either option (1) or option (2) above instead.

> > Oh, I miss an undock/eject generic device keycode, too.  Can't use EJECTCD
> > to undock...
> > 
> > Again, what you want me to change in that default key code matrix that is
> > not a passive-action key?  I aimed to do the best I could according to the
> > info I have (http://thinkwiki.org/wiki/Default_meanings_of_special_keys).
> 
> Having checked other drivers, it looks like KEY_SWITCHVIDEOMODE is the 
> one used for video toggling. If that's not actually how people are using 
> it, we need to fix that - if it is, I'd just go for it.

This looks like a breakage warning to me.  Better decide once and for all
what this keycode is supposed to do, and document it.  Because switching
video mode is not "switch video output mode", and can easily be confused
with "switch screen resolution", "switch video mode between expanded and
normal" or whatever.

> As for the passive keys - I can (with a very high level of certainty) 
> assert that there is no existing userspace that will be broken by 
> sending the brightness keys. We can quibble over the volume ones, but 
> even there the breakage is minimal.

Can't we just fix the damn thing instead?  I am really, really grossed out
by that abuse of the input layer.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: ACPI: thinkpad-acpi: make the input event mode the default

[Dmitry Torokhov]

On 7/15/07, Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> wrote:
> On Mon, 16 Jul 2007, Matthew Garrett wrote:
> >
> > Having checked other drivers, it looks like KEY_SWITCHVIDEOMODE is the
> > one used for video toggling. If that's not actually how people are using
> > it, we need to fix that - if it is, I'd just go for it.
>
> This looks like a breakage warning to me.  Better decide once and for all
> what this keycode is supposed to do, and document it.  Because switching
> video mode is not "switch video output mode", and can easily be confused
> with "switch screen resolution", "switch video mode between expanded and
> normal" or whatever.
>

I will add a comment to input.h to the effect that KEY_SWITCHVIDEOMODE
is to switch between available outputs (LCD/Monitor/TV-Out/Whatnot).
Right now couple of RCs are using it for different purposes (cycling
through inputs I think) so we should do somethig about these.

-- 
Dmitry

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: make the input event mode the default

[Henrique de Moraes Holschuh]

On Mon, 16 Jul 2007, Dmitry Torokhov wrote:
> I will add a comment to input.h to the effect that KEY_SWITCHVIDEOMODE
> is to switch between available outputs (LCD/Monitor/TV-Out/Whatnot).
> Right now couple of RCs are using it for different purposes (cycling
> through inputs I think) so we should do somethig about these.

I will add KEY_SWITCHVIDEOMODE to FN+F7 (thinkpad cycle output video port
key), then.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

ACPI: thinkpad_acpi: use bool for boolean parameters

[Henrique de Moraes Holschuh]

Some of the module parameters are boolean in nature.  Make it so in fact.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
---
 drivers/misc/thinkpad_acpi.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 78e4110..44aa8c9 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -4444,10 +4444,10 @@ static u32 dbg_level;
 module_param_named(debug, dbg_level, uint, 0);
 
 static int force_load;
-module_param(force_load, int, 0);
+module_param(force_load, bool, 0);
 
 static int fan_control_allowed;
-module_param_named(fan_control, fan_control_allowed, int, 0);
+module_param_named(fan_control, fan_control_allowed, bool, 0);
 
 #define IBM_PARAM(feature) \
 	module_param_call(feature, set_ibm_param, NULL, NULL, 0)
-- 
1.5.2.1