On Thu, Aug 2, 2012 at 12:33 PM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > On Thu, Aug 2, 2012 at 12:31 PM, Luca Tettamanti <kronos.it@xxxxxxxxx> wrote: >> On Thu, Aug 2, 2012 at 5:03 PM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: >>> I admit I'm not really an ACPI expert, but thinking about this more, >>> I'm wondering if maybe we should just send the appropriate brightness >>> change, switch display, etc. event to userspace rather than handling >>> it directly in the radeon driver, then let userspace callback down via >>> the bl interface, etc. With backlight for example, does handling it >>> in the kernel driver as per your patch prevent userspace from seeing >>> the brightness up/down event? Wouldn't that break things like OSD >>> brightness displays and such? >> >> No, the event is sent to userspace by the standard ACPI video driver, >> it works as before. >> Changing brightness usually goes like this: >> 1) user presses a hotkey >> 2) a notification is generated (0x86 or 0x87) >> 3) video.ko handles the notification and calls into ACPI to change the >> level (_BCM) and firmware does its magic >> 4) a key press (brightness up/down) is sent to userspace >> >> With ATIF step 3 does not actually change the brightness, it just send >> out another event (VIDEO_PROBE, or one of the device specific ones) so >> we need to take care of that too. The rest of the process, including >> the delivery of the key presses, stays the same. Updated tree with fixes to a few existing patches and improved support for ATPX and initial support for ATCS: http://cgit.freedesktop.org/~agd5f/linux/?h=acpi_patches Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
