lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 29 Apr 2009 11:08:20 +0800
From:	Zhang Rui <rui.zhang@...el.com>
To:	Maxim Levitsky <maximlevitsky@...il.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 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-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

Powered by Openwall GNU/*/Linux Powered by OpenVZ