Planning to write a patch

[Umair Khan]

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 at gmail.com> wrote:

> On Wed, Aug 26, 2015 at 2:16 PM, Umair Khan <omerjerk at gmail.com> wrote:
> >
> >
> > On Wed, Aug 26, 2015 at 11:21 PM, Kenneth Adam Miller
> > <kennethadammiller at gmail.com> 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 at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150826/84bde84e/attachment.html