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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
