Re: patch for video.c driver

Re: patch for video.c driver

[Zhang Rui]

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

cc linux-acpi mail list to get more comments. :)
the patch in the original email is also attached.

On Thu, 2009-03-12 at 23:47 +0800, Terence Ripperda wrote:
> Hello,
> 
> I work on the Linux driver team at nvidia and we've been working on improving
> our notebook support. One area that we're working on is improved hotkey
> support for display switching.
> 
> As you may know, notebooks tend to vary quite a bit in architecture. For the
> majority of notebooks, the current video.ko driver works great for routing
> hotkey events to userspace for higher level drivers to handle. But there are
> some notebooks that use different mechanisms to support hotkeys. For nvidia,
> this is via an NVIF ACPI extension (my understanding is that other vendors
> have similar extensions).

I saw NVIF method implemented on some laptops, but not one is using it.
so do you mean there will be a Nvidia platform specific driver using
NVIF for hotkeys?

> 
> NVIDIA would like to be able to support these extensions,

that's a good news. :)

> using the standard
> video.ko driver. To support this (in a neutral manner), our team has put
> together a patch to allow registration of generic ACPI methods to deliver
> events back to acpid.

I'm a little confused here.
First, NVIF is usually defined as a control method of an ACPI video bus
device. And this is why you want to support this in the generic ACPI
video driver, rather than a platform specific driver like the others,
right?
But I didn't see this piece of code(poking NVIF) in the patch below.
If you do this in another patch, please send the full patch set here. :)

>  The intent was to follow the same architecture that the
> video.ko driver already follows and to make the support generic enough for
> many different users. For example, above I mentioned that both NVIDIA and
> other vendors have ACPI extension methods, the support we're adding would be
> usable by all such vendors.

Makes sense, although the other vendors usually offers a platform
specific device rather than a platform specific control method.

> 
> The idea is that a higher level driver (for example, acpid) can request that a
> new method be enabled via the procfs interface to the video.ko driver.

If we need such an I/F, we'd better introduce a sysfs I/F rather than a
procfs one, because the ACPI procfs I/F is marked as deprecated and will
be removed sooner or later.

>  The
> video.ko driver would then register this method for incoming events.

But I see that only user space can register the customized method and
events, and ACPI video driver do nothing but sending the events to user
space again.
So my question is that, why would we need "char method_name[5];" in
"struct custom_method_data"?

>  Upon
> receiving these events, the video.ko would pass them on to the higher level
> drivers for processing.

the higher level drivers means user space here, right?

Thanks,
rui


[-- Attachment #2: video.c.3.patch --]
[-- Type: text/x-patch, Size: 5631 bytes --]

--- linux-2.6.28/drivers/acpi/video.c.orig	2009-03-06 08:40:07.000000000 -0600
+++ linux-2.6.28/drivers/acpi/video.c	2009-03-06 08:40:07.000000000 -0600
@@ -57,6 +57,7 @@
 #define ACPI_VIDEO_NOTIFY_DISPLAY_OFF		0x89
 
 #define MAX_NAME_LEN	20
+#define MAX_CUSTOM_METHODS		10
 
 #define ACPI_VIDEO_DISPLAY_CRT	1
 #define ACPI_VIDEO_DISPLAY_TV	2
@@ -132,9 +133,15 @@ struct acpi_video_enumerated_device {
 	struct acpi_video_device *bind_info;
 };
 
+struct custom_method_data {
+	char method_name[5]; 
+	u32  method_event_id;
+};
+
 struct acpi_video_bus {
 	struct acpi_device *device;
 	u8 dos_setting;
+	struct custom_method_data method_data[MAX_CUSTOM_METHODS];
 	struct acpi_video_enumerated_device *attached_array;
 	u8 attached_count;
 	struct acpi_video_bus_cap cap;
@@ -233,6 +240,15 @@ static struct file_operations acpi_video
 	.release = single_release,
 };
 
+static int acpi_video_bus_custom_METHODS_open_fs(struct inode *inode,
+						 struct file *file);
+static struct file_operations acpi_video_bus_custom_METHODS_fops = {
+	.open = acpi_video_bus_custom_METHODS_open_fs,
+	.read = seq_read,
+	.llseek = seq_lseek,
+	.release = single_release,
+};
+
 /* device */
 static int acpi_video_device_info_open_fs(struct inode *inode,
 					  struct file *file);
@@ -1291,6 +1307,24 @@ static int acpi_video_bus_DOS_seq_show(s
 	return 0;
 }
 
+static int acpi_video_bus_custom_METHODS_seq_show(struct seq_file *seq,
+						  void *offset)
+{
+	struct acpi_video_bus *video = seq->private;
+	int ctr = 0;
+
+	seq_printf(seq, "Custom methods:	Event-IDs\n");
+	for (ctr = 0; (video->method_data[ctr].method_name[0] != '\0') 
+			&& (ctr < MAX_CUSTOM_METHODS); ctr++) {
+		seq_printf(seq, "%s		0x%x\n", 
+			         video->method_data[ctr].method_name,
+			         video->method_data[ctr].method_event_id);
+	}
+
+	return 0;
+}
+
+
 static int acpi_video_bus_POST_open_fs(struct inode *inode, struct file *file)
 {
 	return single_open(file, acpi_video_bus_POST_seq_show,
@@ -1302,6 +1336,13 @@ static int acpi_video_bus_DOS_open_fs(st
 	return single_open(file, acpi_video_bus_DOS_seq_show, PDE(inode)->data);
 }
 
+static int acpi_video_bus_custom_METHODS_open_fs(struct inode *inode, 
+						 struct file *file)
+{
+	return single_open(file, acpi_video_bus_custom_METHODS_seq_show, 
+				 PDE(inode)->data);
+}
+
 static ssize_t
 acpi_video_bus_write_POST(struct file *file,
 			  const char __user * buffer,
@@ -1373,6 +1414,46 @@ acpi_video_bus_write_DOS(struct file *fi
 	return count;
 }
 
+static ssize_t
+acpi_video_bus_write_custom_METHODS(struct file *file,
+			 const char __user * buffer,
+			 size_t count, loff_t * data)
+{
+	struct seq_file *m = file->private_data;
+	struct acpi_video_bus *video = m->private;
+	char str[12] = { 0 };
+	int data_ctr = 0;
+	int ctr = 0;
+	
+
+	if (!video || count + 1 > sizeof(str))
+		return -EINVAL;
+
+	if (copy_from_user(str, buffer, count))
+		return -EFAULT;
+	
+	str[count] = 0;
+
+	while (video->method_data[ctr].method_name[0] != '\0') 
+		ctr++;
+
+	if (ctr+1 == MAX_CUSTOM_METHODS)
+		return -EFAULT;
+
+	while ((str[data_ctr] != '\0') && !(isspace(str[data_ctr])))
+		data_ctr++;
+
+	if (data_ctr > 4)
+		return -EFAULT;
+
+	strncpy(video->method_data[ctr].method_name, str, data_ctr);
+	video->method_data[ctr].method_name[data_ctr] = '\0';
+	video->method_data[ctr].method_event_id = strtoul(&str[data_ctr+1],
+							  NULL, 0);
+
+	return count;
+}
+
 static int acpi_video_bus_add_fs(struct acpi_device *device)
 {
 	struct acpi_video_bus *video = acpi_driver_data(device);
@@ -1424,9 +1505,20 @@ static int acpi_video_bus_add_fs(struct 
 	if (!entry)
 		goto err_remove_post;
 
+	/* 'custom_METHODS' [R/W] */
+	acpi_video_bus_custom_METHODS_fops.write = acpi_video_bus_write_custom_METHODS;
+	entry = proc_create_data("custom_METHODS", S_IFREG | S_IRUGO | S_IRUSR,
+				 device_dir,
+				 &acpi_video_bus_custom_METHODS_fops,
+				 acpi_driver_data(device));
+	if (!entry)
+		goto err_remove_dos;
+
 	video->dir = acpi_device_dir(device) = device_dir;
 	return 0;
 
+ err_remove_dos:
+	remove_proc_entry("DOS", device_dir);
  err_remove_post:
 	remove_proc_entry("POST", device_dir);
  err_remove_post_info:
@@ -1450,6 +1542,7 @@ static int acpi_video_bus_remove_fs(stru
 		remove_proc_entry("POST_info", device_dir);
 		remove_proc_entry("POST", device_dir);
 		remove_proc_entry("DOS", device_dir);
+		remove_proc_entry("custom_METHODS", device_dir);
 		remove_proc_entry(acpi_device_bid(device), acpi_video_dir);
 		acpi_device_dir(device) = NULL;
 	}
@@ -1836,6 +1929,8 @@ static void acpi_video_bus_notify(acpi_h
 	struct acpi_device *device = NULL;
 	struct input_dev *input;
 	int keycode;
+	int ctr = 0;
+	int custom_event = 0;
 
 	if (!video)
 		return;
@@ -1872,8 +1967,18 @@ static void acpi_video_bus_notify(acpi_h
 		break;
 
 	default:
+		while ((video->method_data[ctr].method_name[0] != '\0') &&
+				ctr < MAX_CUSTOM_METHODS) {  
+ 			if (event == video->method_data[ctr].method_event_id) { 
+				acpi_bus_generate_proc_event(device, event, 0);
+				custom_event = 1;
+				break;
+			}
+			ctr++;
+		}
 		keycode = KEY_UNKNOWN;
-		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+		if (!custom_event)
+			ACPI_DEBUG_PRINT((ACPI_DB_INFO,
 				  "Unsupported event [0x%x]\n", event));
 		break;
 	}
@@ -1990,6 +2095,7 @@ static int acpi_video_bus_add(struct acp
 	video->device = device;
 	strcpy(acpi_device_name(device), ACPI_VIDEO_BUS_NAME);
 	strcpy(acpi_device_class(device), ACPI_VIDEO_CLASS);
+	memset(video->method_data, 0, MAX_CUSTOM_METHODS * sizeof(struct custom_method_data));
 	device->driver_data = video;
 
 	acpi_video_bus_find_cap(video);

Re: patch for video.c driver

[Matthew Garrett]

On Fri, Mar 13, 2009 at 10:08:12AM +0800, Zhang Rui wrote:
> On Thu, 2009-03-12 at 23:47 +0800, Terence Ripperda wrote:
> >  The intent was to follow the same architecture that the
> > video.ko driver already follows and to make the support generic enough for
> > many different users. For example, above I mentioned that both NVIDIA and
> > other vendors have ACPI extension methods, the support we're adding would be
> > usable by all such vendors.
> 
> Makes sense, although the other vendors usually offers a platform
> specific device rather than a platform specific control method.

Mm. I don't see any reason for video output switching to be handled in 
kernel. It's fundamentally behaviour that depends on the user's 
preferences, so the logical way to handle this is for the event to be 
sent to userland (as it is currently) and for a userspace agent to then 
turn this into an xrandr event. The only thing that currently prevents 
this from working with the binary nvidia drivers is the fact that they 
don't appear to support xrandr for output control. I'd prefer it if we 
didn't work around X driver shortcomings by adding interfaces to the 
kernel.

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

Re: patch for video.c driver

[Rafael J. Wysocki]

On Friday 13 March 2009, Matthew Garrett wrote:
> On Fri, Mar 13, 2009 at 10:08:12AM +0800, Zhang Rui wrote:
> > On Thu, 2009-03-12 at 23:47 +0800, Terence Ripperda wrote:
> > >  The intent was to follow the same architecture that the
> > > video.ko driver already follows and to make the support generic enough for
> > > many different users. For example, above I mentioned that both NVIDIA and
> > > other vendors have ACPI extension methods, the support we're adding would be
> > > usable by all such vendors.
> > 
> > Makes sense, although the other vendors usually offers a platform
> > specific device rather than a platform specific control method.
> 
> Mm. I don't see any reason for video output switching to be handled in 
> kernel. It's fundamentally behaviour that depends on the user's 
> preferences, so the logical way to handle this is for the event to be 
> sent to userland (as it is currently) and for a userspace agent to then 
> turn this into an xrandr event. The only thing that currently prevents 
> this from working with the binary nvidia drivers is the fact that they 
> don't appear to support xrandr for output control. I'd prefer it if we 
> didn't work around X driver shortcomings by adding interfaces to the 
> kernel.

FWIW, agreed.

Thanks,
Rafael

Re: patch for video.c driver

[Terence Ripperda]

On Thu, Mar 12, 2009 at 08:00:30PM -0700, mjg59@srcf.ucam.org wrote:
> On Fri, Mar 13, 2009 at 10:08:12AM +0800, Zhang Rui wrote:
> > On Thu, 2009-03-12 at 23:47 +0800, Terence Ripperda wrote:
> > >  The intent was to follow the same architecture that the
> > > video.ko driver already follows and to make the support generic enough for
> > > many different users. For example, above I mentioned that both NVIDIA and
> > > other vendors have ACPI extension methods, the support we're adding would be
> > > usable by all such vendors.
> > 
> > Makes sense, although the other vendors usually offers a platform
> > specific device rather than a platform specific control method.
> 
> Mm. I don't see any reason for video output switching to be handled in 
> kernel. It's fundamentally behaviour that depends on the user's 
> preferences, so the logical way to handle this is for the event to be 
> sent to userland (as it is currently) and for a userspace agent to then 
> turn this into an xrandr event. The only thing that currently prevents 
> this from working with the binary nvidia drivers is the fact that they 
> don't appear to support xrandr for output control. I'd prefer it if we 
> didn't work around X driver shortcomings by adding interfaces to the 
> kernel.

agreed, but that misunderstands the intent of this patch.

I consider hotkeys as 3 pieces:
- delivery of system event to a control mechanism (sbios/acpi/video.ko)
- control mechanism logic (to decide what to do) (userspace daemon)
- display change actions (xrandr support)

although the later 2 pieces can be common to all platforms, unfortunately
notebook vendors tend to be extremely customized, meaning mechanisms vary
greatly between vendors and even products of a single vendor. in a perfect
world, all vendors would follow the basic mechanism the video.c driver
implements (many do). unfortunately, we don't live in that world.

in the case I'm trying to fix here, a vendor is using the NVIF ACPI
extensions, rather than the DGS/DCS methods. not all vendors use these, but for
the ones that do, there's no other way to get the hotkey information. our fix
here is to update the video.c driver to acknowledge the NVIF methods and pass
the methods on to the userspace daemon.

we were attempting to make the patch more generic than just NVIF. no additional
kernel patches would be necessary. userspace logic to write the method name to
the video.ko is needed (the intent here is that the method name could be NVIF on
nvidia or something else for other vendors). if an NVIF specific approach is
desired, we could clean up the patch to specifically enable NVIF methods.


in terms of the higher level logic layers,

currently the nvidia X driver handles the control logic and display change
actions on our boards. this was written a couple of years ago and due to nothing
else in place at the time. we'd prefer to switch to a more generic mechanism in
line with what the community is working on. my understanding is that there is
work on a daemon that relies on X RandR 1.2. I would like nvidia to get involved
in and support that effort. (and I admit nvidia is behind on getting our X RandR
support up to 1.2)

even once that's done, you'd still need the patch (or a similar patch) I'm
suggesting for this infrastructure to work on NVIF-based platforms. userspace
logic for parsing the NVIF methods would also be needed; I'm working on getting
sign-off to release that IP for general linux support.



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

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Re: patch for video.c driver

[Matthew Garrett]

On Fri, Mar 13, 2009 at 12:36:04PM -0500, Terence Ripperda wrote:

> in the case I'm trying to fix here, a vendor is using the NVIF ACPI
> extensions, rather than the DGS/DCS methods. not all vendors use these, but for
> the ones that do, there's no other way to get the hotkey information. our fix
> here is to update the video.c driver to acknowledge the NVIF methods and pass
> the methods on to the userspace daemon.

I'm not quite clear on what you mean by the hotkey information here. As 
far as I'm aware, we don't use DCS/DGS support for anything on Linux 
since it often seems to be either broken or just filled with incorrect 
information.

> currently the nvidia X driver handles the control logic and display change
> actions on our boards. this was written a couple of years ago and due to nothing
> else in place at the time. we'd prefer to switch to a more generic mechanism in
> line with what the community is working on. my understanding is that there is
> work on a daemon that relies on X RandR 1.2. I would like nvidia to get involved
> in and support that effort. (and I admit nvidia is behind on getting our X RandR
> support up to 1.2)
> 
> even once that's done, you'd still need the patch (or a similar patch) I'm
> suggesting for this infrastructure to work on NVIF-based platforms. userspace
> logic for parsing the NVIF methods would also be needed; I'm working on getting
> sign-off to release that IP for general linux support.

Yeah, this is the bit I don't understand. The design we've adopted for 
output switching ignores any BIOS provided information, and instead just 
enables outputs based on the user preferences. The X driver then has 
responsibility for performing the actual switch. Nouveau appears to be 
able to handle this on nvidia platforms without any problem. So, really, 
I guess I'm not clear on what functionality NVIF is intended to provide 
here. Is it impossible to enable outputs on some systems without it?

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

Re: patch for video.c driver

[Terence Ripperda]

On Fri, Mar 13, 2009 at 10:47:26AM -0700, mjg59@srcf.ucam.org wrote:
> On Fri, Mar 13, 2009 at 12:36:04PM -0500, Terence Ripperda wrote:
> 
> > in the case I'm trying to fix here, a vendor is using the NVIF ACPI
> > extensions, rather than the DGS/DCS methods. not all vendors use these, but for
> > the ones that do, there's no other way to get the hotkey information. our fix
> > here is to update the video.c driver to acknowledge the NVIF methods and pass
> > the methods on to the userspace daemon.
> 
> I'm not quite clear on what you mean by the hotkey information here. As 
> far as I'm aware, we don't use DCS/DGS support for anything on Linux 
> since it often seems to be either broken or just filled with incorrect 
> information.

heh, I suspect that "incorrect information" is some of the per-vendor
customization.

our X driver currently handles hotkeys itself, by registering with acpid and
interacting with the video.ko driver. the video.ko driver passes the DCS/DGS
information to us via acpid & procfs. acpid alerts us to the hotkey and we use
procfs to get the DCS/DGS info. the display device ids returned by the SBIOS
tend to follow the ACPI spec, but there are a lot of customized cases. Nvidia
opted to implement these to avoid OEM confusion between Linux & Windows (display
switching order).


> > currently the nvidia X driver handles the control logic and display change
> > actions on our boards. this was written a couple of years ago and due to nothing
> > else in place at the time. we'd prefer to switch to a more generic mechanism in
> > line with what the community is working on. my understanding is that there is
> > work on a daemon that relies on X RandR 1.2. I would like nvidia to get involved
> > in and support that effort. (and I admit nvidia is behind on getting our X RandR
> > support up to 1.2)
> > 
> > even once that's done, you'd still need the patch (or a similar patch) I'm
> > suggesting for this infrastructure to work on NVIF-based platforms. userspace
> > logic for parsing the NVIF methods would also be needed; I'm working on getting
> > sign-off to release that IP for general linux support.
> 
> Yeah, this is the bit I don't understand. The design we've adopted for 
> output switching ignores any BIOS provided information, and instead just 
> enables outputs based on the user preferences. The X driver then has 
> responsibility for performing the actual switch. Nouveau appears to be 
> able to handle this on nvidia platforms without any problem. So, really, 
> I guess I'm not clear on what functionality NVIF is intended to provide 
> here. Is it impossible to enable outputs on some systems without it?

yes, this is what I mean by platform customizations. some notebook platforms
will rely on the DCS/DGS methods to perform hotkeys, others will rely on other
mechanisms, such as NVIF methods. I suspect you'll find that nouveau's mechanism
will work on a lot of notebooks, but not work at all on other notebooks.

in your case, are you receiving the acpid hotkey event, then choosing the
display switch order based on user customization/distro defaults? or are you
even just looking for the keypress sequence, independent of the acpi subsystem?

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

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Re: patch for video.c driver

[Matthew Garrett]

On Fri, Mar 13, 2009 at 12:58:12PM -0500, Terence Ripperda wrote:
> On Fri, Mar 13, 2009 at 10:47:26AM -0700, mjg59@srcf.ucam.org wrote:
> > Yeah, this is the bit I don't understand. The design we've adopted for 
> > output switching ignores any BIOS provided information, and instead just 
> > enables outputs based on the user preferences. The X driver then has 
> > responsibility for performing the actual switch. Nouveau appears to be 
> > able to handle this on nvidia platforms without any problem. So, really, 
> > I guess I'm not clear on what functionality NVIF is intended to provide 
> > here. Is it impossible to enable outputs on some systems without it?
> 
> yes, this is what I mean by platform customizations. some notebook platforms
> will rely on the DCS/DGS methods to perform hotkeys, others will rely on other
> mechanisms, such as NVIF methods. I suspect you'll find that nouveau's mechanism
> will work on a lot of notebooks, but not work at all on other notebooks.

Can we make sure we're clear on terminology here? I'm using hotkey 
events to refer purely to the process by which the user hits a key, the 
firmware generates a notification, the kernel catches this notification 
and generates a KEY_SWITCHVIDEOMODE which we then catch in the user 
session.

There's then the issue of actually performing a display output change in 
response to this. This is curently handled by generating an xrandr 
request. The X driver (potentially in combination with the kernel 
driver, in a kernel modesetting world) then enables or disables outputs 
as appropriate.

The actual output changing is related to but not dependent upon the 
hotkey press, as the user may want to change output configuration via 
the graphical UI rather than by hitting the hotkey. So is the NVIF 
functionality required for generating the event in the first place, 
performing the actual output switch or simply providing the firmware's 
preferred set of enabled outputs?

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

Re: patch for video.c driver

[Terence Ripperda]

On Fri, Mar 13, 2009 at 11:06:46AM -0700, mjg59@srcf.ucam.org wrote:
> On Fri, Mar 13, 2009 at 12:58:12PM -0500, Terence Ripperda wrote:
> > On Fri, Mar 13, 2009 at 10:47:26AM -0700, mjg59@srcf.ucam.org wrote:
> > > Yeah, this is the bit I don't understand. The design we've adopted for 
> > > output switching ignores any BIOS provided information, and instead just 
> > > enables outputs based on the user preferences. The X driver then has 
> > > responsibility for performing the actual switch. Nouveau appears to be 
> > > able to handle this on nvidia platforms without any problem. So, really, 
> > > I guess I'm not clear on what functionality NVIF is intended to provide 
> > > here. Is it impossible to enable outputs on some systems without it?
> > 
> > yes, this is what I mean by platform customizations. some notebook platforms
> > will rely on the DCS/DGS methods to perform hotkeys, others will rely on other
> > mechanisms, such as NVIF methods. I suspect you'll find that nouveau's mechanism
> > will work on a lot of notebooks, but not work at all on other notebooks.
> 
> Can we make sure we're clear on terminology here? I'm using hotkey 
> events to refer purely to the process by which the user hits a key, the 
> firmware generates a notification, the kernel catches this notification 
> and generates a KEY_SWITCHVIDEOMODE which we then catch in the user 
> session.
> 
> There's then the issue of actually performing a display output change in 
> response to this. This is curently handled by generating an xrandr 
> request. The X driver (potentially in combination with the kernel 
> driver, in a kernel modesetting world) then enables or disables outputs 
> as appropriate.
> 
> The actual output changing is related to but not dependent upon the 
> hotkey press, as the user may want to change output configuration via 
> the graphical UI rather than by hitting the hotkey. So is the NVIF 
> functionality required for generating the event in the first place, 
> performing the actual output switch or simply providing the firmware's 
> preferred set of enabled outputs?

sure, I sometimes use the wrong terminology; I mean a display change hotkey,
where a keypress generates a display change event via the sbios/acpi subsystem.

I do not mean a case where a userspace daemon detects keypresses independent of
the sbios/acpi/kernel. I was trying to clarify whether nouveau was using such a 
mechanism.

NVIF methods implement both notification and query commands. so it's required
for generating the event and querying the firmware's preferred set of enabled
outputs.

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

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Re: patch for video.c driver

[Matthew Garrett]

On Fri, Mar 13, 2009 at 03:45:44PM -0500, Terence Ripperda wrote:

> NVIF methods implement both notification and query commands. so it's required
> for generating the event and querying the firmware's preferred set of enabled
> outputs.

Ok, got you. In that case the best approach would be for you to add an 
input device to the kernel component of your driver which listens for 
the notification and then generates KEY_SWITCHVIDEOMODE. The right level 
of integration for the preferred set of screens would be to extend the 
video output class to support listing the outputs as well as just 
performing the switches, then register with that if the platform doesn't 
support DGS and co. We're trying to deprecate the proc interfaces, and 
in general platform-specific drivers should hook into generic interfaces 
rather than overloading the functionality of the existing ACPI drivers.

Do you have any examples of machines that have this requirement?
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: patch for video.c driver

[Len Brown]

Terence,

First, I'm delighted to hear from nvidia -- thanks
for reaching out to the Linux community.

a couple of observations...

drivers/acpi/*.c in general, and video.c in particular,
are meant to implement what is documented in the ACPI specification.

Linux has moved the vendor specific drivers (that may use ACPI,
or use vendor-specific ACPI extensions)
to drivers/platform/x86/*.c

That is where I'd generally expect an nvidia-specific ACPI extension to 
live.

Is there any public documentationon how NVIF is supposed to operate?

I have a new snappy Sony laptop that has both nvidia and intel graphics,
and it has an NVIF.  I'm certain that Linux has no idea how to
switch between "Stamina" and "Speed" modes...

But I also have a Lenovo T61 with only Intel graphics,
and it still has an NVIF.  (presumably Lenovo ships one
BIOS for both their Intel and Nvidia based T61's...)
What happens with NVIF in this case?

thanks,
-Len