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 18:06:46 +0000 [thread overview]
Message-ID: <20090313180646.GA3171@srcf.ucam.org> (raw)
In-Reply-To: <20090313175812.GE13342@hygelac>
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
next prev parent reply other threads:[~2009-03-13 18:06 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
2009-03-13 17:58 ` Terence Ripperda
2009-03-13 18:06 ` Matthew Garrett [this message]
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=20090313180646.GA3171@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