| 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
| ||
|
Message-ID: <15e53e180906160133j7055536cqe5b9515704fd4d94@mail.gmail.com> Date: Tue, 16 Jun 2009 09:33:22 +0100 From: Richard Hughes <hughsient@...il.com> To: Alan Jenkins <alan-jenkins@...fmail.co.uk> Cc: gnome-power-manager-list@...me.org, acpi4asus-user@...ts.sourceforge.net, linux-kernel@...r.kernel.org, Corentin Chary <corentin.chary@...il.com>, Darren Salt <linux@...mustbejoking.demon.co.uk> Subject: Re: [gpm] [PATCH 2.6.29] eeepc-laptop: report brightness control events via the input layer On Mon, Jun 15, 2009 at 9:09 AM, Alan Jenkins<alan-jenkins@...fmail.co.uk> wrote: > So during step iii) I think you see the firmware > increase the brightness, then g-p-m decrease the brightness, and then > g-p-m catches up and the brightness increases again. Sorry for not responding sooner, been moving house. I don't think the kernel driver should modify the brightness itself, as that's applying policy. Is this is left to userspace then we can put on policy such as "don't allow brightness to be set below 30%" or "automatically set the brightness using a ambient light sensor, and use the brightness keys to set ambient thresholds". Doing this policy in the driver is the wrong thing to do IMO. Richard. -- 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