| 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: <472A5EBC.7030907@antonello.org> Date: Fri, 02 Nov 2007 00:18:20 +0100 From: jack@...onello.org To: Pavel Machek <pavel@....cz> CC: linux-kernel@...r.kernel.org, rpurdie@...ys.net Subject: Re: [PATCH] backlight dimmer Pavel Machek wrote: > On Sun 2007-10-28 17:10:53, jack@...onello.org wrote: >> Hello, >> this patch implements a macbook like backlight dimmer on >> top of backlight.c. >> >> The dimmer is entirely in kernelspace and is suitable >> for an embedded context in order to avoid the overhead >> of a daemon controlling the backlight. Implementing this >> functionality in userspace has other advantages and is a >> perfectly reasonable alternative, so this patch is >> not the definitive solution. >> >> activate dimmer: >> echo 1 > /sys/devices/virtual/backlight/*/dimmer_control >> >> other attributes (britness levels & timeout): >> /sys/devices/virtual/backlight/*/dimmer_high_level >> /sys/devices/virtual/backlight/*/dimmer_low_level >> /sys/devices/virtual/backlight/*/dimmer_timeout > > I'd say that userspace makes sense here. I'd want backlight to go down > slowly, for example. > > But... maybe undimming should be done in kernel, so it keeps > low,latency? > > Hmm, maybe existing screen blanking infrastructure can be reused? > >> --- linux-2.6.23.1/include/linux/backlight.h 2007-10-12 >> 18:43:44.000000000 +0200 >> +++ b/include/linux/backlight.h 2007-10-28 >> 13:45:21.000000000 +0100 >> @@ -11,6 +11,7 @@ >> #include <linux/device.h> >> #include <linux/mutex.h> >> #include <linux/notifier.h> >> +#include <linux/timeout.h> >> >> /* Notes on locking: > > Your mail client damages patches? > Hi, incremental dimming can be easily implemented on top of this patch. It's just about posting the timeout repeatedly. I will post something in the near future :). I believe the userspace vs kernelspace argument is very arbitrary. As i said, the dimmer can be completely coded in userspace. There are good reasons for that. Userspace apps can work out better than the kernel what the user is doing. If the user is watching a movie for instance, the dimmer should be stopped. However, the patch is just a light addition to backlight.c. If the dimmer is stopped/unused, just a few pointers and some code are wasted. Userspace apps can start, stop and change the timeout value for the dimmer on the fly, as if they were doing the dimming themselves. In this case, userspace only notifies the kernel to stop the dimmer whenever such action is deemed right. Instead when the dimmer is on, which is most of the time, no kernespace/userspace switch is necessary. Changing the brightness might occur every 10 seconds or so. IMHO this is more of a realtime (and thus kernelspace) requirement rather than userspace. This also saves us from having a whole (heavyweight) dedicated process managing such a basic functionality. Finally, implementing the dimmer in kernelspace delivers this functionality everywhere provided Linux is used. No additional software is necessary. This latter would usually have to be tailored to different audiences such as desktop, embedded, whatever. I don't think thunderbird is breaking the patch, since i was able to apply it from my previous posts. However here is a web location for it, just in case: http://www.antonello.org/dimmer/. Please let me know if you can't test it! jacopo - 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