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
| ||
|
Date: Fri, 1 Feb 2008 22:46:12 -0500 From: Len Brown <lenb@...nel.org> To: Andrew Morton <akpm@...ux-foundation.org> Cc: Matthew Garrett <mjg59@...f.ucam.org>, linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org Subject: Re: [PATCH] Rationalise ACPI backlight implementation On Monday 28 January 2008 00:10, Andrew Morton wrote: > On Mon, 28 Jan 2008 01:25:50 +0000 Matthew Garrett <mjg59@...f.ucam.org> wrote: > > > On Sat, Jan 26, 2008 at 10:00:45PM -0800, Andrew Morton wrote: > > > - Create a new /sys node with a new name which has the new semantics. > > > > The semantics are the same as they always have been - values between 0 > > and max_brightness are valid values. If you've made assumptions about > > what max_brightness is, then that's a bug in the userspace application > > rather than a change in the semantics of the interface. > > > > WTH? My (utterly comedic chase-crap-around-the-tree) brightness script > was: > > ( > 0 sh -c "echo $1 > /proc/acpi/sony/brightness" > 0 sh -c "echo $1 > /proc/acpi/sony/brightness_default" > 0 sh -c "echo $1 > /sys/class/backlight/sony/brightness" > 0 sh -c "echo $1 > /sys/class/backlight/thinkpad_screen/brightness" > ) 2>/dev/null > > And yes, I had an rc.local command which assumed that 7 (later 8) is max > brightness. > > You cannot seriously tell me that if we are to change this range from 0-8 > up to 0-100 then this is not a backwards-incompatible change in > semantics. > > My /sys/class/backlight/ directory is presently empty. Rather than trying > to find out why, I think I'll just collapse in laughter. > > Guys, sort it out, please. I think that Matthew got it right. The generic API is unchanged, brightness goes from 0 to max_brighness. What he did was repair systems that use the acpi video driver (which none of akpm's examples above do) such that the generic API works for that case the same as it does with all other video drivers. Andrew, You might check if CONFIG_ACPI_VIDEO=m is set and you can load the "video" module. While the sony may be non-standard and not load, your thinkpad may work. thanks, -Len -- 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