[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
Alex Deucher
alexdeucher at gmail.com
Fri Jul 27 06:21:11 PDT 2012
On Fri, Jul 27, 2012 at 12:46 AM, joeyli <jlee at suse.com> wrote:
> 於 四,2012-07-26 於 23:31 -0400,Alex Deucher 提到:
>> On Thu, Jul 26, 2012 at 10:50 PM, joeyli <jlee at 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.
>>
>> Alex
>>
>
> 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.
>
>
> 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?
>
> + * flags
> + * bits 1:0:
> + * 0 - Notify(VGA, 0x81) is not used for notification
> + * 1 - Notify(VGA, 0x81) is used for notification
>
> Per the above flags, when we detect bit set to 1, means 0x81 used for radeon-acpi
> to be a general notification event. My question is: what's the event number for
> ACPI_VIDEO_NOTIFY_PROBE on this AMD/ATI machine when 0x81 not available for acpi/video?
>
+/* ARG0: ATIF_FUNCTION_GET_SYSTEM_PARAMETERS
+ * ARG1: none
+ * OUTPUT:
+ * WORD - structure size in bytes (includes size field)
+ * DWORD - valid flags mask
+ * DWORD - flags
+ *
+ * OR
+ *
+ * WORD - structure size in bytes (includes size field)
+ * DWORD - valid flags mask
+ * DWORD - flags
+ * BYTE - notify command code
+ *
+ * flags
+ * bits 1:0:
+ * 0 - Notify(VGA, 0x81) is not used for notification
+ * 1 - Notify(VGA, 0x81) is used for notification
+ * 2 - Notify(VGA, n) is used for notification where
+ * n (0xd0-0xd9) is specified in notify command code.
+ * bit 2:
+ * 1 - lid changes not reported though int10
+ */
if bits 1:0 == 0, there is no notify event for radeon. When bits 1:0
== 1, it uses 0x81; when bits 1:0 == 2 it uses the event number
specified in the following byte (notify command code) which would be
something in the 0xd0-0xd9 range.
Alex
More information about the dri-devel
mailing list