Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code

From: Luca Tettamanti <kronos.it@gmail.com>
To: joeyli <jlee@suse.com>
Cc: linux-acpi@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Alex Deucher <alexander.deucher@amd.com>,
	Zhang Rui <rui.zhang@intel.com>
Subject: Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code
Date: Fri, 27 Jul 2012 11:02:50 +0200	[thread overview]
Message-ID: <20120727090250.GA12716@growl> (raw)
In-Reply-To: <1343364410.8142.42.camel@linux-s257.site>

On Fri, Jul 27, 2012 at 12:46:50PM +0800, joeyli wrote:
> 於 四，2012-07-26 於 23:31 -0400，Alex Deucher 提到：
> > On Thu, Jul 26, 2012 at 10:50 PM, joeyli <jlee@suse.com> wrote:
> > > 於 四，2012-07-26 於 14:58 +0200，Luca Tettamanti 提到：
> > >> - again ACPI video module gets the nodification (in this case
> > >>   ACPI_VIDEO_NOTIFY_PROBE), re-enumerated and send KEY_SWITCHVIDEOMODE
> > >> - KDE seems this and muck with the screen configuration :(
> > >> - meanwhile the brightness notification is propagated, the
> > >> hypothetical
> > >>   radeon driver does its magic to adjust the screen.
> > >>
> > >> My first idea would be to make ACPI_VIDEO_NOTIFY_PROBE also call to
> > >> the
> > >> acpi notifier chain, and allow the handlers to veto the key press
> > >> (like
> > >> it's done for ACPI_VIDEO_NOTIFY_SWITCH).
> > >
> > > I welcome this approach!
> > >
> > > On some ATI machine's DSDT also issue ACPI_VIDEO_NOTIFY_PROBE when
> > > AC-power unplug, because BIOS want to nodify video driver do some power
> > > saving stuff.
> > > It causes KEY_SWITCHVIDEOMODE issued by acpi/video driver when AC-power
> > > unplug.
> > >
> > > At least acpi/video driver need to know this 0x81 event is filed by BIOS
> > > to radeon-acpi for notify but not do video mode switch. That means the
> > > radeon drm need take the video switch responsibility.
> > 
> > Probably we'd just want the radeon acpi handler to just forward the
> > events to userspace so that the user can choose what to do with it
> > (xrandr command, etc.), otherwise we'll need to define policy in the
> > driver.
> 
> Any kernel module can issue KEY_SWITCHVIDEOMODE to user space, then
> gnome-settings-daemon(on Gnome) and  krandr(on KDE) will call xrandr
> library to switch video mode.

Exacly, and if we have pending system bios requests then the event is
not a real ACPI_VIDEO_NOTIFY_PROBE and (IMHO) it should not be forwarded
to the userspace as such.
The "vanilla" ACPI_VIDEO_NOTIFY_PROBE is already forwared to userspace.

> The 0x81 ACPI event for acpi/video driver is ACPI_VIDEO_NOTIFY_PROBE,
> means need issue KEY_SWITCHVIDEOMODE. But, 0x81 for radeon is a general
> notification event.
> I didn't see probe state in GET_SYSTEM_BIOS_REQUESTS, how can we
> distinguish this 0x81 is a ACPI_VIDEO_NOTIFY_PROBE or a ATI general
> notification event?

+#define ATIF_FUNCTION_GET_SYSTEM_BIOS_REQUESTS                     0x2
+/* ARG0: ATIF_FUNCTION_GET_SYSTEM_BIOS_REQUESTS
+ * ARG1: none
+ * OUTPUT:
+ * WORD  - structure size in bytes (includes size field)
+ * DWORD - pending sbios requests
+ * BYTE  - panel expansion mode
+ * BYTE  - thermal state: target gfx controller
+ * BYTE  - thermal state: state id (0: exit state, non-0: state)
+ * BYTE  - forced power state: target gfx controller
+ * BYTE  - forced power state: state id
+ * BYTE  - system power source
+ * BYTE  - panel backlight level (0-255)

I guess that if "pending sbios requests" == 0 then the event is the
general purpose one, and is not handled by radeon driver.

Luca
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel