linux-kernel - Re: [PATCH 1/3] backlight: Allow drivers to update the core, and generate events on changes

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]

Message-ID: <20090714155409.GA31991@khazad-dum.debian.net>
Date:	Tue, 14 Jul 2009 12:54:09 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
	rpurdie@...ys.net, lenb@...nel.org, rui.zhang@...el.com,
	corentincj@...aif.net
Subject: Re: [PATCH 1/3] backlight: Allow drivers to update the core, and
 generate events on changes

On Tue, 14 Jul 2009, Matthew Garrett wrote:
> On Tue, Jul 14, 2009 at 07:30:07AM -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 13 Jul 2009, Matthew Garrett wrote:
> > > Certain hardware will send us events when the backlight brightness
> > > changes. Add a function to update the value in the core, and
> > > additionally send a uevent so that userspace can pop up appropriate
> > > UI. The uevents are flagged depending on whether the update originated
> > > in the kernel or from userspace, making it easier to only display UI
> > > at the appropriate time.
> > 
> > Any reasons to not do it using poll() support (since sysfs has it)?  Or at
> > least, do both poll and uevents?
> 
> More code? It doesn't really seem necessary.

Well, we all know just how marvelously engineered and high-bandwidth the
uevent+udev+everything else channel is, don't we?

Adding the poll() notification is not expensive, one line to do it, plus a
few more to find out the exact sysfs node that needs to receive the
notification (hideous API, that).

> > Other than that, I like the idea a lot.  thinkpad-acpi will use this event
> > support.
> 
> Good, that's one of the use-cases I wanted to deal with - but the hotkey 
> mask stuff is complicated enough that I hadn't got round to touching 
> that yet. The combination of this and the ALSA mixer code should get us 
> full notification.

Leave it to me.  Even if it arrives a bit later than the main patch, it
won't cause problems for the merging of the main work anyway, and as you
said, it *IS* hairy code to do it right and it plugs right in the middle of
the more confusing parts of thinkpad-acpi.  I will do it in a way that makes
the whole thing also usable for the mixer notifications.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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/