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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux