From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Terence Ripperda <tripperda@nvidia.com>
Cc: Zhang Rui <rui.zhang@intel.com>,
"lenb@kernel.org" <lenb@kernel.org>,
linux-acpi <linux-acpi@vger.kernel.org>
Subject: Re: patch for video.c driver
Date: Fri, 13 Mar 2009 17:47:26 +0000 [thread overview]
Message-ID: <20090313174726.GA2888@srcf.ucam.org> (raw)
In-Reply-To: <20090313173604.GB13342@hygelac>
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
next prev parent reply other threads:[~2009-03-13 17:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090312154741.GA1055@hygelac>
2009-03-13 2:08 ` patch for video.c driver Zhang Rui
2009-03-13 3:00 ` Matthew Garrett
2009-03-13 17:11 ` Rafael J. Wysocki
2009-03-13 17:36 ` Terence Ripperda
2009-03-13 17:47 ` Matthew Garrett [this message]
2009-03-13 17:58 ` Terence Ripperda
2009-03-13 18:06 ` Matthew Garrett
2009-03-13 20:45 ` Terence Ripperda
2009-03-13 20:52 ` Matthew Garrett
2009-03-14 7:55 ` Len Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090313174726.GA2888@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=rui.zhang@intel.com \
--cc=tripperda@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox