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 platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
