acpi 'video' driver, and issues with 'brightness_switch_enabled=0'

acpi 'video' driver, and issues with 'brightness_switch_enabled=0'

[Maxim Levitsky]

I have a notebook which handles brightness keys in hardware, but tells
loudly when it does so.

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.

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.

So what you can suggest here?

Regards,
	Maxim Levitsky

Re: acpi 'video' driver, and issues with 'brightness_switch_enabled=0'

[Zhang Rui]

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?

> 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.

> 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/...

what's the model name of your laptop?
are you using Intel graphics?
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.

thanks,
rui

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: acpi 'video' driver, and issues with 'brightness_switch_enabled=0'

[Maxim Levitsky]

[-- Attachment #1: Type: text/plain, Size: 2350 bytes --]

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.

> 
> > 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.

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.


> 
> what's the model name of your laptop?
acer aspire 5720G
> 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.
> 
> thanks,
> rui

Thanks too,
	Best regards,
		Maxim Levitsky

[-- Attachment #2: acpidump.bz2 --]
[-- Type: application/x-bzip, Size: 42936 bytes --]

[-- Attachment #3: lspci.bz2 --]
[-- Type: application/x-bzip, Size: 8319 bytes --]

Re: acpi 'video' driver, and issues with 'brightness_switch_enabled=0'

[Zhang Rui]

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


--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: acpi 'video' driver, and issues with 'brightness_switch_enabled=0'

[Maxim Levitsky]

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

Re: acpi 'video' driver, and issues with 'brightness_switch_enabled=0'

[Maxim Levitsky]

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?
If 'video' acpi driver is loader, otherwise no events

> 
> 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.
If it sets the brightness that is.
/sys/class/backlight/acpi_video0/brightness reflects last value written
to it.
> 
> 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.


maxim@maxim-laptop:~$ grep . /sys/class/backlight/acpi_video0/*
/sys/class/backlight/acpi_video0/actual_brightness:3
/sys/class/backlight/acpi_video0/bl_power:0
/sys/class/backlight/acpi_video0/brightness:7
/sys/class/backlight/acpi_video0/max_brightness:9
maxim@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
maxim@maxim-laptop:~$ 



Note the above with brightness_switch_enabled=0, and with hal
laptop_panel.brightness_in_hardware=true

Which makes it ignore key-presses.

And thus everyting almost work, but OSD of gpm doesn't reflect the
current brightness (it uses /sys/class/backlight/acpi_video0/brightness
it seems)

> 
> > 
> > > 
> > > 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
And like to make linux better in any way I can

> 
> why not move this discussion to the bugzilla so that I can better track
> this bug?

done: http://bugzilla.kernel.org/show_bug.cgi?id=13210

> 
> thanks,
> rui
> 
> 

Best regards,
	Maxim Levitsky

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html