On Apr 22, 2011 11:06 AM, "Anthony Campbell" <ac@acampbell.org.uk> wrote:
>
> On 22 Apr 2011, shawn wilson wrote:
> > On Tue, Apr 19, 2011 at 12:14 PM, Anthony Campbell <ac@acampbell.org.uk> wrote:
> > > My HP laptop tends to boot with a dim screen. I can fix this with
> > >
> > > echo 10 > /sys/devices/virtual/backlight/acpi_video0/brightness
> > >
> > > which I run from /etc/rc,local.
> > >
> >
> > the right way would be to use sysctl. that said, i always do things
> > the way you've done it :)
> >
> > > It works well with all kernels up to 2.6.37. With 2.6.38 there is
> > > usually no /sys/devices/virtual/backlight... so the above command
> > > can't work.
> > >
> >
> > i'd check the kernel changelog or maybe the debian kernel package
> > changelog and see if something was changed for sysfs and see why. i'm
> > not sure whether this line of question is appropriate for that forum,
> > but if it is, someone on debian-dev should know. (reading through the
> > archives, they seem to be hard asses on topicality, so i'd do my
> > research first). also, you could try to ask on irc in #kernel
> >
> > > What is really odd is that if I first boot with a 2.6.37 kernel and then
> > > reboot with a 2.6.38 version, everything works correctly. The file I
> > > need to modify is there and there is full brightness.
> > >
> >
> > iirc, this is stored in ram. i'll bet if you booted in the one kernel,
> > and then did a shutdown -h and immediately powered up into the newer
> > kernel, you'd notice a fail. that said, i think this is improper
> > behavior. you didn't mention what version of debian you're running?
> > ie, i don't think this happens onstable (than again, i'm only on .32,
> > so...)
> >
> > > Is this perhaps something to do with udev? I've found ubuntu bug
> > > reports describing somewhat similar problems but mostly with backlight
> > > being too bright rather than too dim.
> > >
> >
> > i would think it is more in the kernel than in udev. (i think udev
> > gets its info from sysfs and proc - that's probably a bad way of
> > stating this though. it's fron the kernel at any rate)
> >
> > > I would make a bug report if I knew which package was at fault. Can
> > > anyone shed any light (literally)? It's an annoyance rather than a major
> > > problem but I've been trying to figure it out for at least two weeks
> > > wthout success,
> > >
> >
> > this does sound like a bug. it's at least an issue with some default
> > config. if you can, swap out discs and do a fresh install and see what
> > happens. i'm pretty sure you'll notice the same thing. however, that
> > would be the right thing to do before putting in a bug report (and it
> > would be great of you to follow up on this - helps the community and
> > all)
> >
>
> Many thanks for these comments. I'll look into the kernel changelog
> files though I find them pretty intimidating these days. Time was when I
> used to compile my own kernels, but for a long time now I've settled for
> a quiet life and just install the standard Debian kernels. But you are
> probably right to say that it's a kernel problem. When it goes wrong, it
> starts up bright but then goes dim at a certain point in the boot
> process. I couldn't see anything in dmesg to explain this but I'll have
> another look.
>
Might try turning on all kernel logging and look to see if there's any logging hook for proc, sysfs, and udev.
If it is bright when you first turn the machine on and then dims, the goal would be to synchronize a clock with your computer (ntp?) and look at the time when it goes dim and see what happened at that point.
It is completely possible that your backlight function got moved into a more appropriate place where other utilities know about it and some setting is too low for you by default.