http://bugzilla.kernel.org/show_bug.cgi?id=13210
Zhang Rui <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO CC| |[email protected] | |orge.net AssignedTo|acpi_power-vi...@kernel-bug |[email protected] |s.osdl.org | --- Comment #3 from Zhang Rui <[email protected]> 2009-04-30 02:50:34 --- Yakui, acpidump can be gotten from bug #13121 and your suggestion is not helpful for this bug. Now, I think we should make clear 1. if the brightness is changed by BIOS or by AML code. 2. what does gpm use for brightness control, /sys/class/backlight/.../brightness vs actual_brightness (In reply to comment #0) > > Thus a single (say brightness up) event results in brightness going 4 levels > up: > > 1 due to hardware change, agree > 1 for acpi video driver automatic chager, agree, this can be enabled/disable via brightness_switch_enable. > 1 by gpm listening to acpi event device, and finally 1 due to normal keypress. I'm confused here. the "finally 1 due to normal keypress", you mean the input event for the keypress, right? how does gpm catch acpi event? or catch what kind of events? I think these two are the same. IMO, there are three parts in all, when pressing a hotkey 1. an ACPI interrupt is generated 2. an ACPI notification is send to ACPI video driver as a result of the ACPI interrupt 3. ACPI video driver exports an input event to userspace upon the notification Backlight can be changed in either 1(BIOS/AML), 2(ACPI video driver), or 3(userspace app). The problem here is that if it's done in step 1, which is out of OS's control, we should be able to prevent the actions in step 2 and step 3. And it seems that brightness_switch_enabled and with hal laptop_panel.brightness_in_hardware flags are just for this purpose. If I'm right, the only problem left is that OSD shows incorrect brightness level, right? IMO, there could be two reasons. 1. OSD uses /sys/.../brightness, like you said 2. when hal laptop_panel.brightness_in_hardware is set, hal just ignore the event totally, i.e. even not re-query the current brightness level upon this event. this is gotten from your previous email, ma...@maxim-laptop:~$ grep . /sys/class/backlight/acpi_video0/* /sys/class/backlight/acpi_video0/actual_brightness:2 /sys/class/backlight/acpi_video0/bl_power:0 /sys/class/backlight/acpi_video0/brightness:7 /sys/class/backlight/acpi_video0/max_brightness:9 what does OSD show in this case? a level of 7? please change the backlight via this sysfs I/F, e.g. echo 4 > /sys/class/backlight/acpi_video0/brightness, then press the brightness up hotkey, what does OSD show now? a level of 5 or still 7? -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are watching the assignee of the bug. ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
