[patch 11/12] new sony_acpi driver

[patch 11/12] new sony_acpi driver

[akpm-3NddpPZAyC0]

From: Stelian Pop <stelian-ibX4/ixPftWsTnJN9+BGXg@public.gmane.org>

- thanks to beta testers, we have determined that the 'pbr' entry
  corresponds to the default brightness of the panel (the brightness level on
  boot).  This entry has been always activated (not only in debug mode) and
  has been called 'brightness_default'

- thanks to beta testers, we have determined that the 'cdp' entry
  corresponds to the power line on the cdrom drive.  Writing 1 to this entry
  powers on the cd drive, writing 0 powers it off.  This entry has been
  activated in all modes and is now called 'cdpower'

- rewrote a bit part of the driver in a more extensible way: instead of
  having separate functions for getting/settting each parameter, make generic
  ones.  Each entry is now described by a 'sony_acpi_value' structure which
  contains its name, its ACPI get function, its ACPI set function, its minimum
  and maximum values (if pertinent), and a boolean telling if the entry should
  be visible only in debug mode.

- before creating the entry in /proc, test if the entry is supported by the
  ACPI BIOS.  This lets us define some entries that are not supported on all
  Vaio laptops, and these won't be shown in this case (a good example is
  'cdpower')

Signed-off-by: Andrew Morton <akpm-3NddpPZAyC0@public.gmane.org>
---

 25-akpm/Documentation/acpi/sony_acpi.txt |   87 ++++++
 25-akpm/drivers/acpi/Kconfig             |   15 +
 25-akpm/drivers/acpi/Makefile            |    1 
 25-akpm/drivers/acpi/sony_acpi.c         |  392 +++++++++++++++++++++++++++++++
 4 files changed, 495 insertions(+)

diff -puN /dev/null Documentation/acpi/sony_acpi.txt
--- /dev/null	2003-09-15 06:40:47.000000000 -0700
+++ 25-akpm/Documentation/acpi/sony_acpi.txt	2005-02-23 01:48:11.000000000 -0800
@@ -0,0 +1,87 @@
+ACPI Sony Notebook Control Driver (SNC) Readme
+----------------------------------------------
+	Copyright (C) 2004- 2005 Stelian Pop <stelian-ibX4/ixPftWsTnJN9+BGXg@public.gmane.org>
+
+This mini-driver drives the ACPI SNC device present in the
+ACPI BIOS of the Sony Vaio laptops.
+
+It gives access to some extra laptop functionalities. In
+its current form, this driver is mainly useful for controlling the
+screen brightness, but it may do more in the future.
+
+You should probably start by trying the sonypi driver, and try
+sony_acpi only if sonypi doesn't work for you.
+
+Usage:
+------
+
+Loading the sony_acpi module will create a /proc/acpi/sony/
+directory populated with a couple of files.
+
+You then read/write integer values from/to those files by using
+standard UNIX tools.
+
+The files are:
+	brightness		current screen brightness
+	brightness_default	screen brightness which will be set
+				when the laptop will be rebooted
+	cdpower			power on/off the internal CD drive
+
+Note that some files may be missing if they are not supported
+by your particular laptop model.
+
+Example usage:
+	# echo "1" > /proc/acpi/sony/brightness
+sets the lowest screen brightness,
+	# echo "8" > /proc/acpi/sony/brightness
+sets the highest screen brightness,
+	# cat /proc/acpi/sony/brightness
+retrieves the current screen brightness.
+
+Development:
+------------
+
+If you want to help with the development of this driver (and
+you are not afraid of any side effects doing strange things with
+your ACPI BIOS could have on your laptop), load the driver and
+pass the option 'debug=1'.
+
+REPEAT: DON'T DO THIS IF YOU DON'T LIKE RISKY BUSINESS.
+
+In your kernel logs you will find the list of all ACPI methods
+the SNC device has on your laptop. You can see the GBRT/SBRT methods
+used to get/set the brightness, but there are others.
+
+I HAVE NO IDEA WHAT THOSE METHODS DO.
+
+The sony_acpi driver creates, for some of those methods (the most
+current ones found on several Vaio models), an entry under
+/proc/acpi/sony/, just like the 'brightness' one. You can create
+other entries corresponding to your own laptop methods by further
+editing the source (see the 'sony_acpi_values' table, and add a new
+structure to this table with your get/set method names).
+
+Your mission, should you accept it, is to try finding out what
+those entries are for, by reading/writing random values from/to those
+files and find out what is the impact on your laptop.
+
+Should you find anything interesting, please report it back to me,
+I will not disavow all knowledge of your actions :)
+
+Bugs/Limitations:
+-----------------
+
+* This driver is not based on official documentation from Sony
+  (because there is none), so there is no guarantee this driver
+  will work at all, or do the right thing. Although this hasn't
+  happened to me, this driver could do very bad things to your
+  laptop, including permanent damage.
+
+* The sony_acpi and sonypi drivers do not interact at all. In the
+  future, sonypi could use sony_acpi to do (part of) its business.
+
+* spicctrl, which is the userspace tool used to communicate with the
+  sonypi driver (through /dev/sonypi) does not try to use the
+  sony_acpi driver. In the future, spicctrl could try sonypi first,
+  and if it isn't present, try sony_acpi instead.
+
diff -puN drivers/acpi/Kconfig~new-sony_acpi-driver drivers/acpi/Kconfig
--- 25/drivers/acpi/Kconfig~new-sony_acpi-driver	2005-02-23 01:48:11.000000000 -0800
+++ 25-akpm/drivers/acpi/Kconfig	2005-02-23 01:48:11.000000000 -0800
@@ -258,6 +258,21 @@ config ACPI_PCC
 	   If you have one of the above listed Panasonic laptops
 	   say Y or M here.
 
+config ACPI_SONY
+	tristate "Sony Laptop Extras"
+	depends on X86
+	depends on ACPI_INTERPRETER
+	default m
+	  ---help---
+	  This mini-driver drives the ACPI SNC device present in the
+	  ACPI BIOS of the Sony Vaio laptops.
+
+	  It gives access to some extra laptop functionalities. In
+	  its current form, the only thing this driver does is letting
+	  the user set or query the screen brightness.
+
+	  Read <file:Documentation/acpi/sony_acpi.txt> for more information.
+
 config ACPI_CUSTOM_DSDT
 	bool "Include Custom DSDT"
 	depends on ACPI_INTERPRETER && !STANDALONE
diff -puN drivers/acpi/Makefile~new-sony_acpi-driver drivers/acpi/Makefile
--- 25/drivers/acpi/Makefile~new-sony_acpi-driver	2005-02-23 01:48:11.000000000 -0800
+++ 25-akpm/drivers/acpi/Makefile	2005-02-23 01:48:11.000000000 -0800
@@ -54,6 +54,7 @@ obj-$(CONFIG_ACPI_NUMA)		+= numa.o
 obj-$(CONFIG_ACPI_ASUS)		+= asus_acpi.o
 obj-$(CONFIG_ACPI_IBM)		+= ibm_acpi.o
 obj-$(CONFIG_ACPI_TOSHIBA)	+= toshiba_acpi.o
+obj-$(CONFIG_ACPI_SONY)		+= sony_acpi.o
 obj-$(CONFIG_ACPI_PCC)		+= pcc_acpi.o
 obj-$(CONFIG_ACPI_BUS)		+= scan.o motherboard.o
 obj-$(CONFIG_ACPI_HOTPLUG_MEMORY)	+= acpi_memhotplug.o
diff -puN /dev/null drivers/acpi/sony_acpi.c
--- /dev/null	2003-09-15 06:40:47.000000000 -0700
+++ 25-akpm/drivers/acpi/sony_acpi.c	2005-02-23 01:48:11.000000000 -0800
@@ -0,0 +1,392 @@
+/*
+ * ACPI Sony Notebook Control Driver (SNC)
+ *
+ * Copyright (C) 2004-2005 Stelian Pop <stelian-ibX4/ixPftWsTnJN9+BGXg@public.gmane.org>
+ *
+ * Parts of this driver inspired from asus_acpi.c and ibm_acpi.c
+ * which are copyrighted by their respective authors.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/acpi_bus.h>
+#include <asm/uaccess.h>
+
+#define ACPI_SNC_CLASS		"sony"
+#define ACPI_SNC_HID		"SNY5001"
+#define ACPI_SNC_DRIVER_NAME	"ACPI Sony Notebook Control Driver v0.2"
+
+#define LOG_PFX			KERN_WARNING "sony_acpi: "
+
+MODULE_AUTHOR("Stelian Pop");
+MODULE_DESCRIPTION(ACPI_SNC_DRIVER_NAME);
+MODULE_LICENSE("GPL");
+
+static int debug;
+module_param(debug, int, 0);
+MODULE_PARM_DESC(debug, "set this to 1 (and RTFM) if you want to help "
+			"the development of this driver");
+
+static int sony_acpi_add (struct acpi_device *device);
+static int sony_acpi_remove (struct acpi_device *device, int type);
+
+static struct acpi_driver sony_acpi_driver = {
+	.name	= ACPI_SNC_DRIVER_NAME,
+	.class	= ACPI_SNC_CLASS,
+	.ids	= ACPI_SNC_HID,
+	.ops	= {
+			.add	= sony_acpi_add,
+			.remove	= sony_acpi_remove,
+		  },
+};
+
+static acpi_handle sony_acpi_handle;
+static struct proc_dir_entry *sony_acpi_dir;
+
+static struct sony_acpi_value {
+	char			*name;	 /* name of the entry */
+	struct proc_dir_entry 	*proc;	 /* /proc entry */
+	char			*acpiget;/* name of the ACPI get function */
+	char			*acpiset;/* name of the ACPI get function */
+	int 			min;	 /* minimum allowed value or -1 */
+	int			max;	 /* maximum allowed value or -1 */
+	int			debug;	 /* active only in debug mode ? */
+} sony_acpi_values[] = {
+	{
+		.name		= "brightness",
+		.acpiget	= "GBRT",
+		.acpiset	= "SBRT",
+		.min		= 1,
+		.max		= 8,
+		.debug		= 0,
+	},
+	{
+		.name		= "brightness_default",
+		.acpiget	= "GPBR",
+		.acpiset	= "SPBR",
+		.min		= 1,
+		.max		= 8,
+		.debug		= 0,
+	},
+	{
+		.name		= "cdpower",
+		.acpiget	= "GCDP",
+		.acpiset	= "SCDP",
+		.min		= -1,
+		.max		= -1,
+		.debug		= 0,
+	},
+	{
+		.name		= "PID",
+		.acpiget	= "GPID",
+		.debug		= 1,
+	},
+	{
+		.name		= "CTR",
+		.acpiget	= "GCTR",
+		.acpiset	= "SCTR",
+		.min		= -1,
+		.max		= -1,
+		.debug		= 1,
+	},
+	{
+		.name		= "PCR",
+		.acpiget	= "GPCR",
+		.acpiset	= "SPCR",
+		.min		= -1,
+		.max		= -1,
+		.debug		= 1,
+	},
+	{
+		.name		= "CMI",
+		.acpiget	= "GCMI",
+		.acpiset	= "SCMI",
+		.min		= -1,
+		.max		= -1,
+		.debug		= 1,
+	},
+	{
+		.name		= NULL,
+	}
+};
+
+static int acpi_callgetfunc(acpi_handle handle, char *name, int *result)
+{
+	struct acpi_buffer output;
+	union acpi_object out_obj;
+	acpi_status status;
+
+	output.length = sizeof(out_obj);
+	output.pointer = &out_obj;
+
+	status = acpi_evaluate_object(handle, name, NULL, &output);
+	if ((status == AE_OK) && (out_obj.type == ACPI_TYPE_INTEGER)) {
+		*result = out_obj.integer.value;
+		return 0;
+	}
+
+	printk(LOG_PFX "acpi_callreadfunc failed\n");
+
+	return -1;
+}
+
+static int acpi_callsetfunc(acpi_handle handle, char *name, int value,
+			    int *result)
+{
+	struct acpi_object_list params;
+	union acpi_object in_obj;
+	struct acpi_buffer output;
+	union acpi_object out_obj;
+	acpi_status status;
+
+	params.count = 1;
+	params.pointer = &in_obj;
+	in_obj.type = ACPI_TYPE_INTEGER;
+	in_obj.integer.value = value;
+
+	output.length = sizeof(out_obj);
+	output.pointer = &out_obj;
+
+	status = acpi_evaluate_object(handle, name, &params, &output);
+	if (status == AE_OK) {
+		if (result != NULL) {
+			if (out_obj.type != ACPI_TYPE_INTEGER) {
+				printk(LOG_PFX "acpi_evaluate_object bad "
+				       "return type\n");
+				return -1;
+			}
+			*result = out_obj.integer.value;
+		}
+		return 0;
+	}
+
+	printk(LOG_PFX "acpi_evaluate_object failed\n");
+
+	return -1;
+}
+
+static int parse_buffer(const char __user *buffer, unsigned long count,
+			int *val) {
+	char s[32];
+	int ret;
+
+	if (count > 31)
+		return -EINVAL;
+	if (copy_from_user(s, buffer, count))
+		return -EFAULT;
+	s[count] = '\0';
+	ret = simple_strtoul(s, NULL, 10);
+	*val = ret;
+	return 0;
+}
+
+static int sony_acpi_read(char* page, char** start, off_t off, int count,
+			  int* eof, void *data)
+{
+	struct sony_acpi_value *item = data;
+	int value;
+
+	if (!item->acpiget)
+		return -EIO;
+
+	if (acpi_callgetfunc(sony_acpi_handle, item->acpiget, &value) < 0)
+		return -EIO;
+
+	return sprintf(page, "%d\n", value);
+}
+
+static int sony_acpi_write(struct file *file, const char __user *buffer,
+			   unsigned long count, void *data)
+{
+	struct sony_acpi_value *item = data;
+	int result;
+	int value;
+
+	if (!item->acpiset)
+		return -EIO;
+
+	if ((result = parse_buffer(buffer, count, &value)) < 0)
+		return result;
+
+	if (item->min != -1 && value < item->min)
+		return -EINVAL;
+	if (item->max != -1 && value > item->max)
+		return -EINVAL;
+
+	if (acpi_callsetfunc(sony_acpi_handle, item->acpiset, value, NULL) < 0)
+		return -EIO;
+
+	return count;
+}
+
+static void sony_acpi_notify(acpi_handle handle, u32 event, void *data)
+{
+	printk(LOG_PFX "sony_acpi_notify\n");
+}
+
+static acpi_status sony_walk_callback(acpi_handle handle, u32 level,
+				      void *context, void **return_value)
+{
+	struct acpi_namespace_node *node;
+	union acpi_operand_object *operand;
+
+	node = (struct acpi_namespace_node *) handle;
+	operand = (union acpi_operand_object *) node->object;
+
+	printk(LOG_PFX "method: name: %4.4s, args %X\n", node->name.ascii,
+	       (u32) operand->method.param_count);
+
+	return AE_OK;
+}
+
+static int __init sony_acpi_add(struct acpi_device *device)
+{
+	acpi_status status;
+	int result;
+	struct sony_acpi_value *item;
+
+	sony_acpi_handle = device->handle;
+
+	acpi_driver_data(device) = NULL;
+	acpi_device_dir(device) = sony_acpi_dir;
+
+	if (debug) {
+		status = acpi_walk_namespace(ACPI_TYPE_METHOD, sony_acpi_handle,
+					     1, sony_walk_callback, NULL, NULL);
+		if (ACPI_FAILURE(status)) {
+			printk(LOG_PFX "unable to walk acpi resources\n");
+			result = -ENODEV;
+			goto outwalk;
+		}
+
+		status = acpi_install_notify_handler(sony_acpi_handle,
+						     ACPI_DEVICE_NOTIFY,
+						     sony_acpi_notify,
+						     NULL);
+		if (ACPI_FAILURE(status)) {
+			printk(LOG_PFX "unable to install notify handler\n");
+			result = -ENODEV;
+			goto outnotify;
+		}
+	}
+
+	for (item = sony_acpi_values; item->name; ++item) {
+		acpi_handle handle;
+
+		if (!debug && item->debug)
+			continue;
+
+		if (item->acpiget &&
+		    ACPI_FAILURE(acpi_get_handle(sony_acpi_handle,
+		    		 item->acpiget, &handle)))
+		    	continue;
+
+		if (item->acpiset &&
+		    ACPI_FAILURE(acpi_get_handle(sony_acpi_handle,
+		    		 item->acpiset, &handle)))
+		    	continue;
+
+		item->proc = create_proc_entry(item->name, 0600,
+					       acpi_device_dir(device));
+		if (!item->proc) {
+			printk(LOG_PFX "unable to create proc entry\n");
+			result = -EIO;
+			goto outproc;
+		}
+
+		item->proc->read_proc = sony_acpi_read;
+		item->proc->write_proc = sony_acpi_write;
+		item->proc->data = item;
+		item->proc->owner = THIS_MODULE;
+	}
+
+	printk(KERN_INFO ACPI_SNC_DRIVER_NAME " successfully installed\n");
+
+	return 0;
+
+outproc:
+	if (debug) {
+		status = acpi_remove_notify_handler(sony_acpi_handle,
+						    ACPI_DEVICE_NOTIFY,
+						    sony_acpi_notify);
+		if (ACPI_FAILURE(status))
+			printk(LOG_PFX "unable to remove notify handler\n");
+	}
+outnotify:
+	for (item = sony_acpi_values; item->name; ++item)
+		if (item->proc)
+			remove_proc_entry(item->name, acpi_device_dir(device));
+outwalk:
+	return result;
+}
+
+
+static int __exit sony_acpi_remove(struct acpi_device *device, int type)
+{
+	acpi_status status;
+	struct sony_acpi_value *item;
+
+	if (debug) {
+		status = acpi_remove_notify_handler(sony_acpi_handle,
+						    ACPI_DEVICE_NOTIFY,
+						    sony_acpi_notify);
+		if (ACPI_FAILURE(status))
+			printk(LOG_PFX "unable to remove notify handler\n");
+	}
+
+	for (item = sony_acpi_values; item->name; ++item)
+		if (item->proc)
+			remove_proc_entry(item->name, acpi_device_dir(device));
+
+	printk(KERN_INFO ACPI_SNC_DRIVER_NAME " successfully removed\n");
+
+	return 0;
+}
+
+static int __init sony_acpi_init(void)
+{
+	int result;
+
+	sony_acpi_dir = proc_mkdir("sony", acpi_root_dir);
+	if (!sony_acpi_dir) {
+		printk(LOG_PFX "unable to create /proc entry\n");
+		return -ENODEV;
+	}
+	sony_acpi_dir->owner = THIS_MODULE;
+
+	result = acpi_bus_register_driver(&sony_acpi_driver);
+	if (result < 0) {
+		remove_proc_entry("sony", acpi_root_dir);
+		return -ENODEV;
+	}
+	return 0;
+}
+
+
+static void __exit sony_acpi_exit(void)
+{
+	acpi_bus_unregister_driver(&sony_acpi_driver);
+	remove_proc_entry("sony", acpi_root_dir);
+}
+
+module_init(sony_acpi_init);
+module_exit(sony_acpi_exit);
_


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: [patch 11/12] new sony_acpi driver

[Len Brown]

I'd like to keep this driver out-of-tree
until we prove that we can't enhance the
generic code to handle this hardware
without the addition of a new driver.

thanks,
-Len

On Wed, 2005-02-23 at 04:53, akpm-3NddpPZAyC0@public.gmane.org wrote:
> From: Stelian Pop <stelian-ibX4/ixPftWsTnJN9+BGXg@public.gmane.org>
> 
> - thanks to beta testers, we have determined that the 'pbr' entry
>   corresponds to the default brightness of the panel (the brightness
> level on
>   boot).  This entry has been always activated (not only in debug
> mode) and
>   has been called 'brightness_default'
> 
> - thanks to beta testers, we have determined that the 'cdp' entry
>   corresponds to the power line on the cdrom drive.  Writing 1 to this
> entry
>   powers on the cd drive, writing 0 powers it off.  This entry has
> been
>   activated in all modes and is now called 'cdpower'
> 
> - rewrote a bit part of the driver in a more extensible way: instead
> of
>   having separate functions for getting/settting each parameter, make
> generic
>   ones.  Each entry is now described by a 'sony_acpi_value' structure
> which
>   contains its name, its ACPI get function, its ACPI set function, its
> minimum
>   and maximum values (if pertinent), and a boolean telling if the
> entry should
>   be visible only in debug mode.
> 
> - before creating the entry in /proc, test if the entry is supported
> by the
>   ACPI BIOS.  This lets us define some entries that are not supported
> on all
>   Vaio laptops, and these won't be shown in this case (a good example
> is
>   'cdpower')
> 
> Signed-off-by: Andrew Morton <akpm-3NddpPZAyC0@public.gmane.org>
> ---
> 
>  25-akpm/Documentation/acpi/sony_acpi.txt |   87 ++++++
>  25-akpm/drivers/acpi/Kconfig             |   15 +
>  25-akpm/drivers/acpi/Makefile            |    1
>  25-akpm/drivers/acpi/sony_acpi.c         |  392
> +++++++++++++++++++++++++++++++
>  4 files changed, 495 insertions(+)
> 
> diff -puN /dev/null Documentation/acpi/sony_acpi.txt
> --- /dev/null   2003-09-15 06:40:47.000000000 -0700
> +++ 25-akpm/Documentation/acpi/sony_acpi.txt    2005-02-23
> 01:48:11.000000000 -0800
> @@ -0,0 +1,87 @@
> +ACPI Sony Notebook Control Driver (SNC) Readme
> +----------------------------------------------
> +       Copyright (C) 2004- 2005 Stelian Pop <stelian-ibX4/ixPftWsTnJN9+BGXg@public.gmane.org>
> +
> +This mini-driver drives the ACPI SNC device present in the
> +ACPI BIOS of the Sony Vaio laptops.
> +
> +It gives access to some extra laptop functionalities. In
> +its current form, this driver is mainly useful for controlling the
> +screen brightness, but it may do more in the future.
> +
> +You should probably start by trying the sonypi driver, and try
> +sony_acpi only if sonypi doesn't work for you.
> +
> +Usage:
> +------
> +
> +Loading the sony_acpi module will create a /proc/acpi/sony/
> +directory populated with a couple of files.
> +
> +You then read/write integer values from/to those files by using
> +standard UNIX tools.
> +
> +The files are:
> +       brightness              current screen brightness
> +       brightness_default      screen brightness which will be set
> +                               when the laptop will be rebooted
> +       cdpower                 power on/off the internal CD drive
> +
> +Note that some files may be missing if they are not supported
> +by your particular laptop model.
> +
> +Example usage:
> +       # echo "1" > /proc/acpi/sony/brightness
> +sets the lowest screen brightness,
> +       # echo "8" > /proc/acpi/sony/brightness
> +sets the highest screen brightness,
> +       # cat /proc/acpi/sony/brightness
> +retrieves the current screen brightness.
> +
> +Development:
> +------------
> +
> +If you want to help with the development of this driver (and
> +you are not afraid of any side effects doing strange things with
> +your ACPI BIOS could have on your laptop), load the driver and
> +pass the option 'debug=1'.
> +
> +REPEAT: DON'T DO THIS IF YOU DON'T LIKE RISKY BUSINESS.
> +
> +In your kernel logs you will find the list of all ACPI methods
> +the SNC device has on your laptop. You can see the GBRT/SBRT methods
> +used to get/set the brightness, but there are others.
> +
> +I HAVE NO IDEA WHAT THOSE METHODS DO.
> +
> +The sony_acpi driver creates, for some of those methods (the most
> +current ones found on several Vaio models), an entry under
> +/proc/acpi/sony/, just like the 'brightness' one. You can create
> +other entries corresponding to your own laptop methods by further
> +editing the source (see the 'sony_acpi_values' table, and add a new
> +structure to this table with your get/set method names).
> +
> +Your mission, should you accept it, is to try finding out what
> +those entries are for, by reading/writing random values from/to those
> +files and find out what is the impact on your laptop.
> +
> +Should you find anything interesting, please report it back to me,
> +I will not disavow all knowledge of your actions :)
> +
> +Bugs/Limitations:
> +-----------------
> +
> +* This driver is not based on official documentation from Sony
> +  (because there is none), so there is no guarantee this driver
> +  will work at all, or do the right thing. Although this hasn't
> +  happened to me, this driver could do very bad things to your
> +  laptop, including permanent damage.
> +
> +* The sony_acpi and sonypi drivers do not interact at all. In the
> +  future, sonypi could use sony_acpi to do (part of) its business.
> +
> +* spicctrl, which is the userspace tool used to communicate with the
> +  sonypi driver (through /dev/sonypi) does not try to use the
> +  sony_acpi driver. In the future, spicctrl could try sonypi first,
> +  and if it isn't present, try sony_acpi instead.
> +
> diff -puN drivers/acpi/Kconfig~new-sony_acpi-driver
> drivers/acpi/Kconfig
> --- 25/drivers/acpi/Kconfig~new-sony_acpi-driver        2005-02-23
> 01:48:11.000000000 -0800
> +++ 25-akpm/drivers/acpi/Kconfig        2005-02-23 01:48:11.000000000
> -0800
> @@ -258,6 +258,21 @@ config ACPI_PCC
>            If you have one of the above listed Panasonic laptops
>            say Y or M here.
> 
> +config ACPI_SONY
> +       tristate "Sony Laptop Extras"
> +       depends on X86
> +       depends on ACPI_INTERPRETER
> +       default m
> +         ---help---
> +         This mini-driver drives the ACPI SNC device present in the
> +         ACPI BIOS of the Sony Vaio laptops.
> +
> +         It gives access to some extra laptop functionalities. In
> +         its current form, the only thing this driver does is letting
> +         the user set or query the screen brightness.
> +
> +         Read <file:Documentation/acpi/sony_acpi.txt> for more
> information.
> +
>  config ACPI_CUSTOM_DSDT
>         bool "Include Custom DSDT"
>         depends on ACPI_INTERPRETER && !STANDALONE
> diff -puN drivers/acpi/Makefile~new-sony_acpi-driver
> drivers/acpi/Makefile
> --- 25/drivers/acpi/Makefile~new-sony_acpi-driver       2005-02-23
> 01:48:11.000000000 -0800
> +++ 25-akpm/drivers/acpi/Makefile       2005-02-23 01:48:11.000000000
> -0800
> @@ -54,6 +54,7 @@ obj-$(CONFIG_ACPI_NUMA)               += numa.o
>  obj-$(CONFIG_ACPI_ASUS)                += asus_acpi.o
>  obj-$(CONFIG_ACPI_IBM)         += ibm_acpi.o
>  obj-$(CONFIG_ACPI_TOSHIBA)     += toshiba_acpi.o
> +obj-$(CONFIG_ACPI_SONY)                += sony_acpi.o
>  obj-$(CONFIG_ACPI_PCC)         += pcc_acpi.o
>  obj-$(CONFIG_ACPI_BUS)         += scan.o motherboard.o
>  obj-$(CONFIG_ACPI_HOTPLUG_MEMORY)      += acpi_memhotplug.o
> diff -puN /dev/null drivers/acpi/sony_acpi.c
> --- /dev/null   2003-09-15 06:40:47.000000000 -0700
> +++ 25-akpm/drivers/acpi/sony_acpi.c    2005-02-23 01:48:11.000000000
> -0800
> @@ -0,0 +1,392 @@
> +/*
> + * ACPI Sony Notebook Control Driver (SNC)
> + *
> + * Copyright (C) 2004-2005 Stelian Pop <stelian-ibX4/ixPftWsTnJN9+BGXg@public.gmane.org>
> + *
> + * Parts of this driver inspired from asus_acpi.c and ibm_acpi.c
> + * which are copyrighted by their respective authors.
> + *
> + * This program is free software; you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License as published
> by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + *
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/init.h>
> +#include <linux/types.h>
> +#include <acpi/acpi_drivers.h>
> +#include <acpi/acpi_bus.h>
> +#include <asm/uaccess.h>
> +
> +#define ACPI_SNC_CLASS         "sony"
> +#define ACPI_SNC_HID           "SNY5001"
> +#define ACPI_SNC_DRIVER_NAME   "ACPI Sony Notebook Control Driver
> v0.2"
> +
> +#define LOG_PFX                        KERN_WARNING "sony_acpi: "
> +
> +MODULE_AUTHOR("Stelian Pop");
> +MODULE_DESCRIPTION(ACPI_SNC_DRIVER_NAME);
> +MODULE_LICENSE("GPL");
> +
> +static int debug;
> +module_param(debug, int, 0);
> +MODULE_PARM_DESC(debug, "set this to 1 (and RTFM) if you want to help
> "
> +                       "the development of this driver");
> +
> +static int sony_acpi_add (struct acpi_device *device);
> +static int sony_acpi_remove (struct acpi_device *device, int type);
> +
> +static struct acpi_driver sony_acpi_driver = {
> +       .name   = ACPI_SNC_DRIVER_NAME,
> +       .class  = ACPI_SNC_CLASS,
> +       .ids    = ACPI_SNC_HID,
> +       .ops    = {
> +                       .add    = sony_acpi_add,
> +                       .remove = sony_acpi_remove,
> +                 },
> +};
> +
> +static acpi_handle sony_acpi_handle;
> +static struct proc_dir_entry *sony_acpi_dir;
> +
> +static struct sony_acpi_value {
> +       char                    *name;   /* name of the entry */
> +       struct proc_dir_entry   *proc;   /* /proc entry */
> +       char                    *acpiget;/* name of the ACPI get
> function */
> +       char                    *acpiset;/* name of the ACPI get
> function */
> +       int                     min;     /* minimum allowed value or
> -1 */
> +       int                     max;     /* maximum allowed value or
> -1 */
> +       int                     debug;   /* active only in debug mode
> ? */
> +} sony_acpi_values[] = {
> +       {
> +               .name           = "brightness",
> +               .acpiget        = "GBRT",
> +               .acpiset        = "SBRT",
> +               .min            = 1,
> +               .max            = 8,
> +               .debug          = 0,
> +       },
> +       {
> +               .name           = "brightness_default",
> +               .acpiget        = "GPBR",
> +               .acpiset        = "SPBR",
> +               .min            = 1,
> +               .max            = 8,
> +               .debug          = 0,
> +       },
> +       {
> +               .name           = "cdpower",
> +               .acpiget        = "GCDP",
> +               .acpiset        = "SCDP",
> +               .min            = -1,
> +               .max            = -1,
> +               .debug          = 0,
> +       },
> +       {
> +               .name           = "PID",
> +               .acpiget        = "GPID",
> +               .debug          = 1,
> +       },
> +       {
> +               .name           = "CTR",
> +               .acpiget        = "GCTR",
> +               .acpiset        = "SCTR",
> +               .min            = -1,
> +               .max            = -1,
> +               .debug          = 1,
> +       },
> +       {
> +               .name           = "PCR",
> +               .acpiget        = "GPCR",
> +               .acpiset        = "SPCR",
> +               .min            = -1,
> +               .max            = -1,
> +               .debug          = 1,
> +       },
> +       {
> +               .name           = "CMI",
> +               .acpiget        = "GCMI",
> +               .acpiset        = "SCMI",
> +               .min            = -1,
> +               .max            = -1,
> +               .debug          = 1,
> +       },
> +       {
> +               .name           = NULL,
> +       }
> +};
> +
> +static int acpi_callgetfunc(acpi_handle handle, char *name, int
> *result)
> +{
> +       struct acpi_buffer output;
> +       union acpi_object out_obj;
> +       acpi_status status;
> +
> +       output.length = sizeof(out_obj);
> +       output.pointer = &out_obj;
> +
> +       status = acpi_evaluate_object(handle, name, NULL, &output);
> +       if ((status == AE_OK) && (out_obj.type == ACPI_TYPE_INTEGER))
> {
> +               *result = out_obj.integer.value;
> +               return 0;
> +       }
> +
> +       printk(LOG_PFX "acpi_callreadfunc failed\n");
> +
> +       return -1;
> +}
> +
> +static int acpi_callsetfunc(acpi_handle handle, char *name, int
> value,
> +                           int *result)
> +{
> +       struct acpi_object_list params;
> +       union acpi_object in_obj;
> +       struct acpi_buffer output;
> +       union acpi_object out_obj;
> +       acpi_status status;
> +
> +       params.count = 1;
> +       params.pointer = &in_obj;
> +       in_obj.type = ACPI_TYPE_INTEGER;
> +       in_obj.integer.value = value;
> +
> +       output.length = sizeof(out_obj);
> +       output.pointer = &out_obj;
> +
> +       status = acpi_evaluate_object(handle, name, &params, &output);
> +       if (status == AE_OK) {
> +               if (result != NULL) {
> +                       if (out_obj.type != ACPI_TYPE_INTEGER) {
> +                               printk(LOG_PFX "acpi_evaluate_object
> bad "
> +                                      "return type\n");
> +                               return -1;
> +                       }
> +                       *result = out_obj.integer.value;
> +               }
> +               return 0;
> +       }
> +
> +       printk(LOG_PFX "acpi_evaluate_object failed\n");
> +
> +       return -1;
> +}
> +
> +static int parse_buffer(const char __user *buffer, unsigned long
> count,
> +                       int *val) {
> +       char s[32];
> +       int ret;
> +
> +       if (count > 31)
> +               return -EINVAL;
> +       if (copy_from_user(s, buffer, count))
> +               return -EFAULT;
> +       s[count] = '\0';
> +       ret = simple_strtoul(s, NULL, 10);
> +       *val = ret;
> +       return 0;
> +}
> +
> +static int sony_acpi_read(char* page, char** start, off_t off, int
> count,
> +                         int* eof, void *data)
> +{
> +       struct sony_acpi_value *item = data;
> +       int value;
> +
> +       if (!item->acpiget)
> +               return -EIO;
> +
> +       if (acpi_callgetfunc(sony_acpi_handle, item->acpiget, &value)
> < 0)
> +               return -EIO;
> +
> +       return sprintf(page, "%d\n", value);
> +}
> +
> +static int sony_acpi_write(struct file *file, const char __user
> *buffer,
> +                          unsigned long count, void *data)
> +{
> +       struct sony_acpi_value *item = data;
> +       int result;
> +       int value;
> +
> +       if (!item->acpiset)
> +               return -EIO;
> +
> +       if ((result = parse_buffer(buffer, count, &value)) < 0)
> +               return result;
> +
> +       if (item->min != -1 && value < item->min)
> +               return -EINVAL;
> +       if (item->max != -1 && value > item->max)
> +               return -EINVAL;
> +
> +       if (acpi_callsetfunc(sony_acpi_handle, item->acpiset, value,
> NULL) < 0)
> +               return -EIO;
> +
> +       return count;
> +}
> +
> +static void sony_acpi_notify(acpi_handle handle, u32 event, void
> *data)
> +{
> +       printk(LOG_PFX "sony_acpi_notify\n");
> +}
> +
> +static acpi_status sony_walk_callback(acpi_handle handle, u32 level,
> +                                     void *context, void
> **return_value)
> +{
> +       struct acpi_namespace_node *node;
> +       union acpi_operand_object *operand;
> +
> +       node = (struct acpi_namespace_node *) handle;
> +       operand = (union acpi_operand_object *) node->object;
> +
> +       printk(LOG_PFX "method: name: %4.4s, args %X\n",
> node->name.ascii,
> +              (u32) operand->method.param_count);
> +
> +       return AE_OK;
> +}
> +
> +static int __init sony_acpi_add(struct acpi_device *device)
> +{
> +       acpi_status status;
> +       int result;
> +       struct sony_acpi_value *item;
> +
> +       sony_acpi_handle = device->handle;
> +
> +       acpi_driver_data(device) = NULL;
> +       acpi_device_dir(device) = sony_acpi_dir;
> +
> +       if (debug) {
> +               status = acpi_walk_namespace(ACPI_TYPE_METHOD,
> sony_acpi_handle,
> +                                            1, sony_walk_callback,
> NULL, NULL);
> +               if (ACPI_FAILURE(status)) {
> +                       printk(LOG_PFX "unable to walk acpi
> resources\n");
> +                       result = -ENODEV;
> +                       goto outwalk;
> +               }
> +
> +               status = acpi_install_notify_handler(sony_acpi_handle,
> +                                                   
> ACPI_DEVICE_NOTIFY,
> +                                                    sony_acpi_notify,
> +                                                    NULL);
> +               if (ACPI_FAILURE(status)) {
> +                       printk(LOG_PFX "unable to install notify
> handler\n");
> +                       result = -ENODEV;
> +                       goto outnotify;
> +               }
> +       }
> +
> +       for (item = sony_acpi_values; item->name; ++item) {
> +               acpi_handle handle;
> +
> +               if (!debug && item->debug)
> +                       continue;
> +
> +               if (item->acpiget &&
> +                   ACPI_FAILURE(acpi_get_handle(sony_acpi_handle,
> +                                item->acpiget, &handle)))
> +                       continue;
> +
> +               if (item->acpiset &&
> +                   ACPI_FAILURE(acpi_get_handle(sony_acpi_handle,
> +                                item->acpiset, &handle)))
> +                       continue;
> +
> +               item->proc = create_proc_entry(item->name, 0600,
> +                                             
> acpi_device_dir(device));
> +               if (!item->proc) {
> +                       printk(LOG_PFX "unable to create proc
> entry\n");
> +                       result = -EIO;
> +                       goto outproc;
> +               }
> +
> +               item->proc->read_proc = sony_acpi_read;
> +               item->proc->write_proc = sony_acpi_write;
> +               item->proc->data = item;
> +               item->proc->owner = THIS_MODULE;
> +       }
> +
> +       printk(KERN_INFO ACPI_SNC_DRIVER_NAME " successfully
> installed\n");
> +
> +       return 0;
> +
> +outproc:
> +       if (debug) {
> +               status = acpi_remove_notify_handler(sony_acpi_handle,
> +                                                  
> ACPI_DEVICE_NOTIFY,
> +                                                   sony_acpi_notify);
> +               if (ACPI_FAILURE(status))
> +                       printk(LOG_PFX "unable to remove notify
> handler\n");
> +       }
> +outnotify:
> +       for (item = sony_acpi_values; item->name; ++item)
> +               if (item->proc)
> +                       remove_proc_entry(item->name,
> acpi_device_dir(device));
> +outwalk:
> +       return result;
> +}
> +
> +
> +static int __exit sony_acpi_remove(struct acpi_device *device, int
> type)
> +{
> +       acpi_status status;
> +       struct sony_acpi_value *item;
> +
> +       if (debug) {
> +               status = acpi_remove_notify_handler(sony_acpi_handle,
> +                                                  
> ACPI_DEVICE_NOTIFY,
> +                                                   sony_acpi_notify);
> +               if (ACPI_FAILURE(status))
> +                       printk(LOG_PFX "unable to remove notify
> handler\n");
> +       }
> +
> +       for (item = sony_acpi_values; item->name; ++item)
> +               if (item->proc)
> +                       remove_proc_entry(item->name,
> acpi_device_dir(device));
> +
> +       printk(KERN_INFO ACPI_SNC_DRIVER_NAME " successfully
> removed\n");
> +
> +       return 0;
> +}
> +
> +static int __init sony_acpi_init(void)
> +{
> +       int result;
> +
> +       sony_acpi_dir = proc_mkdir("sony", acpi_root_dir);
> +       if (!sony_acpi_dir) {
> +               printk(LOG_PFX "unable to create /proc entry\n");
> +               return -ENODEV;
> +       }
> +       sony_acpi_dir->owner = THIS_MODULE;
> +
> +       result = acpi_bus_register_driver(&sony_acpi_driver);
> +       if (result < 0) {
> +               remove_proc_entry("sony", acpi_root_dir);
> +               return -ENODEV;
> +       }
> +       return 0;
> +}
> +
> +
> +static void __exit sony_acpi_exit(void)
> +{
> +       acpi_bus_unregister_driver(&sony_acpi_driver);
> +       remove_proc_entry("sony", acpi_root_dir);
> +}
> +
> +module_init(sony_acpi_init);
> +module_exit(sony_acpi_exit);
> _
> 
> 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: [patch 11/12] new sony_acpi driver

[Stelian Pop]

On Wed, Mar 02, 2005 at 02:12:40PM -0500, Len Brown wrote:

> I'd like to keep this driver out-of-tree
> until we prove that we can't enhance the
> generic code to handle this hardware
> without the addition of a new driver.

I have no problem keeping it out of the tree, it has been this was
for quite a long time now. Anyway the distro maintainers are starting
to put it into their kernels so it won't be a problem for endusers
any longer. BTW, it was those distro maintainers who asked me to
resubmit the driver lately...

But still, I don't see why there is no place for a sony acpi somewhere
where there are already drivers for ibm, toshiba and asus laptops.

I attached to the bugzilla entry the DSDTs for two Vaio laptops, which
should hopefuly prove that those laptops do not support the standard
ACPI way to access the video. Did you look at them ?

Stelian.
-- 
Stelian Pop <stelian-ibX4/ixPftWsTnJN9+BGXg@public.gmane.org>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: [patch 11/12] new sony_acpi driver

[Timo Hoenig]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

On Wed, 2005-03-02 at 21:53 +0100, Stelian Pop wrote:
[...]
>
>I have no problem keeping it out of the tree, it has been this was
>for quite a long time now. Anyway the distro maintainers are starting
>to put it into their kernels so it won't be a problem for endusers
>any longer. BTW, it was those distro maintainers who asked me to
>resubmit the driver lately...
>
I guess you're talking about me.  I did not contact you being a distro
maintainer.  As developer, my intention was -- and still is -- that we
really should get as many laptop specific functions into mainline as
possible.  I care about happy users.

It's a shame that there are actually drivers out there but users simply
do not benefit from them because they are not merged with mainline.

Anyway, as Len proposed, a generic solution is definitely the best
solution.  Let's get this work done.

>But still, I don't see why there is no place for a sony acpi somewhere
>where there are already drivers for ibm, toshiba and asus laptops.

They will disappear once the generic solution is implemented.

[...]
>
>Stelian.

See you,

  -- Timo

..............................................................
Timo Hönig <thoenig at nouse dot net>
..................................................:: gpg ::...
Fingerprint: 0998 0ACA A1D2 2612 4D96 DD8B E03F 084B B305 4066

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Re: [patch 11/12] new sony_acpi driver

[Stelian Pop]

On Thu, Mar 03, 2005 at 09:40:45AM +0100, Timo Hoenig wrote:

> On Wed, 2005-03-02 at 21:53 +0100, Stelian Pop wrote:
> [...]
> >
> >I have no problem keeping it out of the tree, it has been this was
> >for quite a long time now. Anyway the distro maintainers are starting
> >to put it into their kernels so it won't be a problem for endusers
> >any longer. BTW, it was those distro maintainers who asked me to
> >resubmit the driver lately...
> >
> I guess you're talking about me.

Not only you.

> I did not contact you being a distro
> maintainer.  As developer, my intention was -- and still is -- that we
> really should get as many laptop specific functions into mainline as
> possible.  I care about happy users.

So do I. 

Unhappy users also come bugging me (because I also maintain a non-ACPI
sony driver which did work with older models but works less and less 
with newer ones) and I have to tell them about sony_acpi. Maybe I
should tell them to bug acpi_devel instead ?

> It's a shame that there are actually drivers out there but users simply
> do not benefit from them because they are not merged with mainline.

I fully agree.

> Anyway, as Len proposed, a generic solution is definitely the best
> solution.  Let's get this work done.

Except the generic solution doesn't exist. It could be partly 
implemented (like acpi_video), but it will never be complete.

> >But still, I don't see why there is no place for a sony acpi somewhere
> >where there are already drivers for ibm, toshiba and asus laptops.
> 
> They will disappear once the generic solution is implemented.

Maybe the problem here is that the ACPI based drivers should not
be at all in the ACPI tree.

drivers/acpi contain today both the ACPI layer and the ACPI drivers.
Maybe a split up like the networking code would be saner: $KDIR/acpi
for the layer and $KDIR/drivers/acpi for the drivers using the acpi
API to implements specific drivers.

Stelian.
-- 
Stelian Pop <stelian-ibX4/ixPftWsTnJN9+BGXg@public.gmane.org>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: [patch 11/12] new sony_acpi driver

[Timo Hoenig]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

Hi,

On Thu, 2005-03-03 at 10:39 +0100, Stelian Pop wrote:
[...]
>Maybe the problem here is that the ACPI based drivers should not
>be at all in the ACPI tree.
>
>drivers/acpi contain today both the ACPI layer and the ACPI drivers.
>Maybe a split up like the networking code would be saner: $KDIR/acpi
>for the layer and $KDIR/drivers/acpi for the drivers using the acpi
>API to implements specific drivers.

That sounds good to me.  If this is the way to go, I'd like to see a
discussion with the developers of all already available drivers.

>Stelian.

See you,

   -- Timo

..............................................................
Timo Hönig <thoenig at nouse dot net>
..................................................:: gpg ::...
Fingerprint: 0998 0ACA A1D2 2612 4D96 DD8B E03F 084B B305 4066

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

generic ACPI video and hotkey drivers vs. platform-specific drivers

[Len Brown]

It is great that programmers -- sometimes with little or no
vendor support -- have come up with platform specific
drivers to make things work on their boxes. But
this is only a stepping stone to where we need to be,
for building special drivers for every platform is not
a solution of first choice, it is a solution of last resort.

The total number of systems already deployed and those
in the pipeline is very large when you account for all
the models from all the vendors -- and this number is
increasing, not decreasing.  If we lead the distros
down this path they will get crushed in a support mess.

As I've said before, it is fine with me for exotic drivers
to handle exotic hardware -- nobody wants to muck-up generic
code for a few exotics.  But we need a design where
standard systems we've never heard of "just work";
and we need to make the use, administration, and support
of exotic systems as much like standard sytems
as possible.

I believe that Bruno's generic video driver (in tree)
is a step in this direction.  I believe that Luming's
generic hot key driver (on list, but not yet in tree)
is a step in this direction.  Are either of these
"final"?  heck no, but I'm confident that they're
heading us in the right direction.

I plan to pull Luming's hot-key driver into the ACPI patch
soon -- the only reason we didnt' do it earlyer is because
the previous version would have immediately broken the
existing platform specific drivers...

We also need to think about the kernel<->user interface
we've currently got.

We need to think through the suggestion that hot keys
should appear to Linux like other keyboard keys -- and
wind their way throught the input layer.  I think the important
thing will be what the user or administrator has to do in
order to map which keys to which functions; and if this
can work automatically without a call to 1-800-distro.
Hopefully we can leverage the stuff people use for keyboard
special keys already.

thanks for your support,
-Len




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: generic ACPI video and hotkey drivers vs. platform-specific drivers

[Timo Hoenig]

[-- Attachment #1: Type: text/plain, Size: 3039 bytes --]

Hi,

thanks for opening this discussion.

On Thu, 2005-03-03 at 16:08 -0500, Len Brown wrote:
>It is great that programmers -- sometimes with little or no

[...]

>As I've said before, it is fine with me for exotic drivers
>to handle exotic hardware -- nobody wants to muck-up generic
>code for a few exotics.  But we need a design where
>standard systems we've never heard of "just work";
>and we need to make the use, administration, and support
>of exotic systems as much like standard sytems
>as possible.

Yes.  What do you think of providing an API for specific drivers as
proposed by Stelian on acpi-devel before?  We then could move the
specific drivers out of the ACPI maintree.

Regarding hotkeys for example we could provide an interface which is
used by the specific drivers to report events.  Such events would be
reported into user-space like the one's triggered by the generic driver.
Perhaps by using the Linux input core.  But I guess this still needs to
be discussed thoroughly.

[...]

>I believe that Bruno's generic video driver (in tree)
>is a step in this direction.  I believe that Luming's
>generic hot key driver (on list, but not yet in tree)
>is a step in this direction.  Are either of these
>"final"?  heck no, but I'm confident that they're
>heading us in the right direction.
>
>I plan to pull Luming's hot-key driver into the ACPI patch
>soon -- the only reason we didnt' do it earlyer is because
>the previous version would have immediately broken the
>existing platform specific drivers...

Luming, can you please give some comment on the state of your driver?

>We also need to think about the kernel<->user interface
>we've currently got.
>
>We need to think through the suggestion that hot keys
>should appear to Linux like other keyboard keys -- and
>wind their way throught the input layer.  I think the important
>thing will be what the user or administrator has to do in
>order to map which keys to which functions; and if this
>can work automatically without a call to 1-800-distro.

I will write some document which will pinpoint the current problems
depending on vendor and/or machine.  For that purpose I'll have quite a
few machines provided by the SUSE Labs. For other systems I will call
users for help.

[...]

We still have to face the fact that we will not be able to cover all
systems by a generic driver.  Vendors are -- and will -- go their own
way. See Sony and Toshiba for example.  Since we do not want to clutter
the generic driver with exceptions we will have to find a proper design
for implementing specific drivers.

Maybe the number of systems which require a specific driver will
decrease -- but never to zero.

I've added Andrew and John to cc.

See you,

  -- Timo

..............................................................
Timo Hönig <thoenig at nouse dot net>
..................................................:: gpg ::...
Fingerprint: 0998 0ACA A1D2 2612 4D96 DD8B E03F 084B B305 4066

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: generic ACPI video and hotkey drivers vs. platform-specific drivers

[Pavel Machek]

Hi!

> We need to think through the suggestion that hot keys
> should appear to Linux like other keyboard keys -- and
> wind their way throught the input layer.  I think the important
> thing will be what the user or administrator has to do in
> order to map which keys to which functions; and if this
> can work automatically without a call to 1-800-distro.
> Hopefully we can leverage the stuff people use for keyboard
> special keys already.

There's utility for X called "hotkeys"; it has hw-specific config files, but
on linux it should be possible to have one generic config file. X are usefull
for displaying overlays telling you current volume setting, etc.
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: generic ACPI video and hotkey drivers vs. platform-specific drivers

[=?gb18030?q?Ois=A8=AAn_Mac_Fheara=A8=AA?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 1708 bytes --]

On Sunday 06 March 2005 10:45, Pavel Machek wrote:
> Hi!
>
> > We need to think through the suggestion that hot keys
> > should appear to Linux like other keyboard keys -- and
> > wind their way throught the input layer.  I think the important
> > thing will be what the user or administrator has to do in
> > order to map which keys to which functions; and if this
> > can work automatically without a call to 1-800-distro.
> > Hopefully we can leverage the stuff people use for keyboard
> > special keys already.
>
> There's utility for X called "hotkeys"; it has hw-specific config files,
> but on linux it should be possible to have one generic config file. X are
> usefull for displaying overlays telling you current volume setting, etc.
> 				Pavel

I don't think so - I use hotkeys and I had to mess around with get/setkeycodes 
etc and basically mess around for quite a while with some Acer keyboard 
config file as a template (I'm using an Aspire 1705SMi, which has nothing in 
common with the acerwl keyboard...).

I could only get the kernel to recognize and let me assign one of the keys 
(the fast forward button, annoyingly, under my wrists as I type), which puts 
the machine into S3 sleep.

So... it's a handy utility, but I can't see a "generic" solution (from my 
uneducated accidental wrist-putting-machine-to-sleep hassle point of view).

Ois¨ªn


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: generic ACPI video and hotkey drivers vs. platform-specific drivers

[Stefan Seyfried]

On Fri, Mar 11, 2005 at 04:07:50AM +0000, Oisín Mac Fhearaí wrote:
> On Sunday 06 March 2005 10:45, Pavel Machek wrote:

> > There's utility for X called "hotkeys"; it has hw-specific config files,
> > but on linux it should be possible to have one generic config file. X are
> > usefull for displaying overlays telling you current volume setting, etc.
> > 				Pavel
> 
> I don't think so - I use hotkeys and I had to mess around with get/setkeycodes 
> etc and basically mess around for quite a while with some Acer keyboard 

What pavel wanted to say (IIUC) was, that there are already enough tools
for grabbing "generic" keys (AKA your keyboard) from the input system
and reacting on them, so routing ACPI hotkeys through the input layer
seems a good thing to do. I tend to agree.
 
> So... it's a handy utility, but I can't see a "generic" solution (from my 
> uneducated accidental wrist-putting-machine-to-sleep hassle point of view).

maybe because your acer does not generate "normal" keystrokes for those
buttons but ACPI events? So you would benefit from these solution, too.
-- 
Stefan Seyfried



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: generic ACPI video and hotkey drivers vs. platform-specific drivers

[=?gb18030?q?Ois=A8=AAn_Mac_Fheara=A8=AA?=]

On Friday 11 March 2005 17:43, Stefan Seyfried wrote:
> What pavel wanted to say (IIUC) was, that there are already enough tools
> for grabbing "generic" keys (AKA your keyboard) from the input system
> and reacting on them, so routing ACPI hotkeys through the input layer
> seems a good thing to do. I tend to agree.

Yes, if they all use the same method and all can be made to work consistently 
without a bizarre amount of effort, sure.
>
> maybe because your acer does not generate "normal" keystrokes for those
> buttons but ACPI events? So you would benefit from these solution, too.

It seems to send two-byte scancodes for (some, but not all) keys actually, but 
I could only make one of them work properly. It's a bit confusing.

Checking just now, I noticed that two of the 'user' hotkeys produce a 2 byte 
scancode for keydown and the same value +128 for keyup.

In fact, tailing /proc/acpi/event never produces any output for me, at least 
when I watch it while opening and closing the lid and whacking all the 
hotkeys.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: [patch 11/12] new sony_acpi driver

[Brown, Len]

>But still, I don't see why there is no place for a sony acpi somewhere
>where there are already drivers for ibm, toshiba and asus laptops.

The goal is to DELETE ibm, toshiba, and asus drivers -- or at least the
duplicated functions in them.

platform specific drivers make it harder, not easier, to support more
hardware -- there are a zillion vendors out there, implementing special
drivers for each of them is a strategy of last resort.

>I attached to the bugzilla entry the DSDTs for two Vaio laptops, which
>should hopefuly prove that those laptops do not support the standard
>ACPI way to access the video. Did you look at them ?

thanks for filing the bug, it is in the queue.

-Len


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

Re: [patch 11/12] new sony_acpi driver

[Stelian Pop]

On Wed, Mar 02, 2005 at 05:37:44PM -0500, Brown, Len wrote:

> >But still, I don't see why there is no place for a sony acpi somewhere
> >where there are already drivers for ibm, toshiba and asus laptops.
> 
> The goal is to DELETE ibm, toshiba, and asus drivers -- or at least the
> duplicated functions in them.

Did you look at the code in those drivers ? There is no way you can
delete them because each of them is very specific in the functionalities
it offers and the way to achieve it.

Sure, for basic stuff like the brightness you can hope to have a 
common code (like video.c today). It may even work on future laptops.
But it won't work on older (todays) laptops (I'm not sure about the
other brands, but it won't work on Sony Vaios). And even if when it
works it won't do everything because vendors will always implement
extensions.

And you can choose to either not have access to those extensions
under Linux (which sucks) or have platform specific drivers.

> platform specific drivers make it harder, not easier, to support more
> hardware -- there are a zillion vendors out there, implementing special
> drivers for each of them is a strategy of last resort.

There are hardly "a zillion vendors" in the laptop market. I'd say
that IBM + HP + Sony + Toshiba + Dell form 90+ % of the market.

> >I attached to the bugzilla entry the DSDTs for two Vaio laptops, which
> >should hopefuly prove that those laptops do not support the standard
> >ACPI way to access the video. Did you look at them ?
> 
> thanks for filing the bug, it is in the queue.

The point of the question was to point out that I've already provided
proof that Vaios do not support standard ACPI video methods.

Stelian.
-- 
Stelian Pop <stelian-ibX4/ixPftWsTnJN9+BGXg@public.gmane.org>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: [patch 11/12] new sony_acpi driver

[Timo Hoenig]

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

Hi,

On Thu, 2005-03-03 at 10:27 +0100, Stelian Pop wrote:
>Did you look at the code in those drivers ? There is no way you can
>delete them because each of them is very specific in the functionalities
>it offers and the way to achieve it.
>
>Sure, for basic stuff like the brightness you can hope to have a 
>common code (like video.c today). It may even work on future laptops.
>But it won't work on older (todays) laptops (I'm not sure about the
>other brands, but it won't work on Sony Vaios). And even if when it
>works it won't do everything because vendors will always implement
>extensions.

Since the function implementations vary but their purpose is the same it
would be possible by creating generic wrapper functions (hotkey
implementation, trigger common hardware functions like fan,
bluetooth...).  I'm not sure which way would be the best to cover laptop
specific functions which are not covered by the generic wrapper
functions.

[...]
>
>Stelian.

See you,

  -- Timo

..............................................................
Timo Hönig <thoenig at nouse dot net>
..................................................:: gpg ::...
Fingerprint: 0998 0ACA A1D2 2612 4D96 DD8B E03F 084B B305 4066

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Re: [patch 11/12] new sony_acpi driver

[Stelian Pop]

On Thu, Mar 03, 2005 at 10:34:04AM +0100, Timo Hoenig wrote:

> On Thu, 2005-03-03 at 10:27 +0100, Stelian Pop wrote:
> >Did you look at the code in those drivers ? There is no way you can
> >delete them because each of them is very specific in the functionalities
> >it offers and the way to achieve it.
> >
> >Sure, for basic stuff like the brightness you can hope to have a 
> >common code (like video.c today). It may even work on future laptops.
> >But it won't work on older (todays) laptops (I'm not sure about the
> >other brands, but it won't work on Sony Vaios). And even if when it
> >works it won't do everything because vendors will always implement
> >extensions.
> 
> Since the function implementations vary but their purpose is the same it
> would be possible by creating generic wrapper functions (hotkey
> implementation, trigger common hardware functions like fan,
> bluetooth...).  I'm not sure which way would be the best to cover laptop
> specific functions which are not covered by the generic wrapper
> functions.

It would be nice to have a common API for userspace. Today this
is done at application level (KDE for example, etc), but it would
be nice if, for the generic functionalities, the kernel would
offer the same API (/proc/acpi, /sys, ioctl based, whatever) to the
userland.

But the discussion here is pretty unrelated. We are talking about
the implementation not interface, and what Len wants is to remove
the specific {ibm,toshiba,asus} implementations and make generic ones 
based on the ACPI stantard.

Stelian.
-- 
Stelian Pop <stelian-ibX4/ixPftWsTnJN9+BGXg@public.gmane.org>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: [patch 11/12] new sony_acpi driver

[Timo Hoenig]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

Hi,

On Thu, 2005-03-03 at 10:45 +0100, Stelian Pop wrote:
[...]
>
>But the discussion here is pretty unrelated. We are talking about
>the implementation not interface, and what Len wants is to remove
>the specific {ibm,toshiba,asus} implementations and make generic ones 
>based on the ACPI stantard.

Ah, OK.  I did not get this before.  Then, we've got a problem.  I mean,
when looking at the different implementations of the drivers it is
obvious that this will  not  work at all.  For example, I'm thinking of
the Toshiba HCI which needs to be polled to get hotkey information...

So, I'd really appreciate to see a comment from Len about his thoughts
which way to go.

>Stelian.

See you,

   -- Timo

..............................................................
Timo Hönig <thoenig at nouse dot net>
..................................................:: gpg ::...
Fingerprint: 0998 0ACA A1D2 2612 4D96 DD8B E03F 084B B305 4066

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]