Thanks a lot for this detailed explanation. :) I'll try this. I guess I'll also get to know how patches are sent to be accepted (or rejected for this case) to the kernel.
On Thu 27 Aug, 2015 12:15 am Greg Freemyer <[email protected]> wrote: > On Wed, Aug 26, 2015 at 2:16 PM, Umair Khan <[email protected]> wrote: > > > > > > On Wed, Aug 26, 2015 at 11:21 PM, Kenneth Adam Miller > > <[email protected]> wrote: > >> > >> Well, it's probably worth doing for the sake of your learning. However, > if > >> you are going to get into the source, I think it's highly likely that > you > >> are going to see that the driver provides such a feature to userspace > code > >> through means of an ioctl, and in that case, you will probably be able > to > >> set the brightness programmatically without ever having to interfere > with > >> the driver code itself. So for that matter, the objective doesn't > really fit > >> with the complexity you're taking on. If what I'm saying is right, you > could > >> easily implement this entirely in userland code by writing a binary and > then > >> putting a script in the startup execution so that it calls your binary. > >> > >> If you really want to hack the driver, another way to do it is to just > put > >> the brightness setting in the driver's init function, so that when the > >> module is loaded it turns up the brightness. In that case, you *should* > get > >> what you want because the driver will be loaded at system boot. > >> > >> On Wed, Aug 26, 2015 at 1:45 PM, Umair Khan <[email protected]> wrote: > >>> > >>> Hello everyone, > >>> > >>> I've been thinking of writing a patch a lot lately. But with my level > of > >>> knowledge I cannot do something groundbreaking. > >>> One thing which came to my mind is to write a patch related to the > driver > >>> which controls the brightness of the display. > >>> What happens now is I lower down the brightness, and when I restart the > >>> laptop, it's back to the highest amount. > >>> I'm using Ubuntu 14.04 LTS on top of Linux Kernel 4.2 rc3+. > >>> I was thinking of writing the current brightness to sysfs and read that > >>> value when the driver is started during the boot. > >>> > >>> So, my question is that is it already implemented in the driver and > just > >>> that Ubuntu resets it on every reboot from userspace ? > >>> And if it is not implemented, is it worth implementing ? > >>> > >>> Thanks > >>> Umair > >>> Delhi, India > >>> > >>> > >> > > > > I do get this that, most probably this feature would have been provided > via > > ioctl. And it is better handled inside the userspace. > > But it'd be just like the hardware is intelligent enough to keep the > value > > persistent across reboot. Like the monitor of my PC keeps the brightness, > > and all the different values for that matter, persistent across reboot. > > Userspace can always override this behavior anyways. > > > > Thoughts ? > > > sysfs is a virtual filesystem that is destroyed and recreated on > reboot. It has no persistence, so your initial plan won't work. > > The policy is that sysfs persistence is implemented in userspace so > there simply is no need for sysfs to be persistent. > > RE: Warm reboots only > > A totally different approach is if the laptop's display brightness is > already maintained in a hardware register. That seems very likely, > but I haven't written a hardware driver in a very long time. > > That way on a warm reboot you could code the driver to read in the > brightness from the hardware register instead of forcing it to a > default. > > Thus your first experimental parch would just be to see of the > hardware brightness register can be read. If so, does it maintain its > value through a warm reboot? > > If the hardware register is maintaining the value through a warm > reboot, try to figure out why the brightness is being reset to a > default value. > > Nothing production worthy may come of that, but it lets you experiment > with the code and learn more about how a warm reboot works. > > fyi: cold reboots may (or may not) have a different persistence mechanism. > > Greg >
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
