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