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 <greg.freemyer@xxxxxxxxx> wrote:
On Wed, Aug 26, 2015 at 2:16 PM, Umair Khan <omerjerk@xxxxxxxxx> wrote:
>
>
> On Wed, Aug 26, 2015 at 11:21 PM, Kenneth Adam Miller
> <kennethadammiller@xxxxxxxxx> 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 <omerjerk@xxxxxxxxx> 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 Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
