On Wed, 2009-04-29 at 11:08 +0800, Zhang Rui wrote: > On Tue, 2009-04-28 at 17:58 +0800, Maxim Levitsky wrote: > > On Tue, 2009-04-28 at 10:43 +0800, Zhang Rui wrote: > > > On Tue, 2009-04-28 at 01:57 +0800, Maxim Levitsky wrote: > > > > I have a notebook which handles brightness keys in hardware, but tells > > > > loudly when it does so. > > > > > > > if you boot into console mode w/o ACPI video driver, does the brightness > > > still change when you press the hotkeys? > > They always work. > > For s while, due to buggy ACPI table, acpi 'video' driver won't work, so > > I blacklisted it, and yet hw keys did work. > > > so if you kill acpid, and run "cat /proc/acpi/event", there are some > ACPI video events popping up when you press the hotkeys, right? > > this is bad, because these events are "Used to notify OSPM that the > output device brightness should be increased/decreased by one level. > Used to notify OSPM that the user pressed a button or key that is > associated with cycling brightness." according to the ACPI spec. > So, if BIOS changes the brightness for OS, it should not issue an event > any more. > > > > > > > > Currently, acpi 'video' also sets the brightness, which result in double > > > > setting, and on top of that it emits a key that makes gpm set brightness > > > > again. > > > > > > > we need to support the brightness control in console mode. > > > and "brightness_switch_enabled" should be cleared in graphics mode to > > > prevent the ACPI video driver action upon hotkey events. > > How gnome power manager can do that, use /sys/module iface? > > > > > > > > > And (yes...) on top of that keyboard emits a brightness up/down even, > > > > which (you guessed...) sets brightness again. > > > > > > > > I found out that it is possible to tell gnome-power-manager not to set > > > > brightness, but yet in kernel driver still sets it. > > > > > > > > I found out even earlier that I can use brightness_switch_enabled=0, > > > > which supposed to make inkernel driver not touch the brightness. > > > > But I found out that this driver won't update the brightness, in /sys > > > > interface when I set this param. > > > > > > > No, when "brightness_switch_enabled" is cleared, gdm should still use > > > the ACPI backlight sysfs I/F if available to change the backlight, > > > i.e. /sys/class/backlight/acpi_video0/... > > Indeed it does, but I don't like it, hardware already changed the > > brightness, but it receives another two events about brightness up/down. > > > well, this is rather a hardware problem to me. > Because OS should change the brightness upon such a notification, either > in ACPI video driver, or in user space. > IMO, if BIOS doesn't want OS to change the backlight, it should not > issue such events at all. > > > It (and I too) can change the brightness, but it doesn't update to > > reflect current brightness > > (/sys/class/backlight/acpi_video0/brightness) shows cached value from > > last time it was set. > > > > there is also the actual_brightness, but I think it isn't used by gpm. > > > /sys/class/backlight/acpi_video0/brightness doesn't reflect the actual > brightness level, gdm should use actual_brightness instead. > > But if gdm uses the sysfs backlight I/F, the value of these two files > should be the same. > > can you do this test please? > 1. attach the output of "grep . /sys/class/backlight/acpi_video0/*" > 2. press the hotkey > 3. redo step 1. > > > > > > > > > what's the model name of your laptop? > > acer aspire 5720G > > hah, I know this laptop. > > > are you using Intel graphics? > > no, nvidia 8400GS > > > > > please attach the output of acpidump and lspci. > > > > > It would be great if you can file a bug report about this issue at > > > bugzilla.kernel.org. > > No problem. > And I know you're good at reporting bugs. :p > > why not move this discussion to the bugzilla so that I can better track > this bug? > > thanks, > rui > > I''ll check this. Best regards, Maxim Levitsky -- 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
