linux-kernel - Re: [PATCH] video: backlight: Remove backlight sysfs uevent

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: <20131122113601.GB27196@khazad-dum.debian.net>
Date:	Fri, 22 Nov 2013 09:36:01 -0200
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Jingoo Han <jg1.han@...sung.com>,
	'Kyungmin Park' <kmpark@...radead.org>,
	'Henrique de Moraes Holschuh' <ibm-acpi@....eng.br>,
	linux-fbdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	kay@...y.org, 'Richard Purdie' <rpurdie@...ys.net>,
	ibm-acpi-devel@...ts.sourceforge.net,
	platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH] video: backlight: Remove backlight sysfs uevent

On Thu, 21 Nov 2013, Matthew Garrett wrote:
> On Thu, Nov 21, 2013 at 09:43:32AM -0200, Henrique de Moraes Holschuh wrote:
> > With this patchset applied, as far as I can tell anything that used to be
> > uevent-driven by the backlight class will break: when a process changes the
> > backlight using sysfs, other processes will not be notified of the change
> > anymore.  This patchset seems to break backlight uevent support in such a
> > way that basically renders the entire thing useless and you might as well
> > just remove uevent support entirely.
> 
> The uevent support was initially added to handle systems where pressing 
> a hotkey generates an event (good) but the firmware automatically 
> changes the brightness (bad). I have absolutely no idea why I added 
> BACKLIGHT_UPDATE_SYSFS - BACKLIGHT_UPDATE_HOTKEY solves the problem I 
> was trying to solve. I'm not aware of any userspace that relies on 
> BACKLIGHT_UPDATE_SYSFS.

Well, either we have userspace that rely on the uevents, or we don't. 

If we don't have any uevent users of the backlight notifications, we might
as well just rip out the feature entirely and replace it with something with
a proper design.  But that would mean all OSD is being done by time-based
open-read-close polling of sysfs or keyed to input events (and therefore
half-baked).

However, if we do have anything that rely on the uevents, it needs
BACKLIGHT_UPDATE_SYSFS.  Without it, there will be no notifications when the
backlight level is changed through sysfs.  And we *DO* have applications
that change the backlight level through sysfs.  From the top of my head, I
know KDE does when it starts, and also as a response to power management
events.  Also, userspace hotkey daemons do use the sysfs interface.

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