Message-Id: <1241003731.26698.0.camel@maxim-laptop>
Date:	Wed, 29 Apr 2009 14:15:31 +0300
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Zhang Rui <rui.zhang@...el.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: Re: acpi 'video' driver, and issues with
 'brightness_switch_enabled=0'

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists