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