From: Terence Ripperda <tripperda@nvidia.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Terence Ripperda <TRipperda@nvidia.com>,
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 15:45:44 -0500 [thread overview]
Message-ID: <20090313204544.GR16754@hygelac> (raw)
In-Reply-To: <20090313180646.GA3171@srcf.ucam.org>
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.
-----------------------------------------------------------------------------------
next prev parent reply other threads:[~2009-03-13 20:45 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
2009-03-13 20:45 ` Terence Ripperda [this message]
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=20090313204544.GR16754@hygelac \
--to=tripperda@nvidia.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=rui.zhang@intel.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