linux-kernel - Re: [PATCH] backlight: add support for disabling backlights via sysfs

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:	Thu, 28 Jun 2012 16:16:00 -0500
From:	Seth Forshee <seth.forshee@...onical.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Richard Purdie <rpurdie@...ys.net>, linux-kernel@...r.kernel.org,
	platform-driver-x86@...r.kernel.org,
	Corentin Chary <corentin.chary@...il.com>
Subject: Re: [PATCH] backlight: add support for disabling backlights via sysfs

On Thu, Jun 28, 2012 at 08:36:52PM +0100, Matthew Garrett wrote:
> Userspace should already be prioritising platform interfaces over raw 
> interfaces, so if gmux works on the Mac then there's no problem. DMI 
> lists should, broadly speaking, be unnecessary - they're mostly a 
> symptom of us not understanding how the hardware is expected to work.

I agree that we want to avoid papering over problems instead of fixing
them, but we're already disabling the ACPI backlight in some cases and
will continue to do so for the time being. We're also doing it with
apple_bl. It's not a question of whether we do it, but how.

What I still don't understand is your reason for preferring
driver-specific interfaces for disabling backlights to a single generic
interface. Are you afraid that allowing it to be done from userspace
will make it too easy, and as a result quirks will be applied without
attempting to fix the problem (i.e. the quriking should go through a
kernel dev to ensure someone tries to fix the problem is made before
applying a quirk)?

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