Re: Backlight mystery - anyone shed light? some progress
On 24 Apr 2011, shawn wilson wrote: On Sun, Apr 24, 2011 at 5:10 PM, Anthony Campbell a...@acampbell.org.uk wrote: On 24 Apr 2011, Anthony Campbell wrote: On 24 Apr 2011, Camaleón wrote: Well, it's beginning to look as if it was a hardware problem all along. The Windows partition disappeared and the backlight began to work perfectly. I decided to do a reinstall in the former Windows partition. Everything seemed to go off correctly but when I came to reboot into Debian I got Nonsystem Disk or disk failure: Replace and strike any key when ready. I think there must have been some hardware failure. that's your mbr talking to you. don't think that's hardware 'failure'. Yes -thanks to another kind soul on this always-helpful list, I needed to set the partition with the bootable flag. It then came up at once. It's beginning to look as if the original problem discussed in this thread (dim backlight) was due to the egregious Windows. Now that that is gone the backlight is bright all the time. Much relief. Anthony -- Anthony Campbell - a...@acampbell.org.uk Microsoft-free zone - Using Debian GNU/Linux http://www.acampbell.org.uk - sample my ebooks at http://www.smashwords.com/profile/view/acampbell -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110425080117.gf2...@acampbell.org.uk
Re: Backlight mystery - anyone shed light? some progress
On 23 Apr 2011, Camaleón wrote: This is a laptop (6735s) and is over a year old so not very new. I don't think it has that feature. It uses the radeon driver. You will find out in the BIOS screen. If the feature is there, there should be an option to toggle it on/off under system configuration menu/ buit-in options Also, check for a BIOS update, most of these ACPI things are usually fixed after updating to the latest BIOS. Thanks, Camaleon. I found a lot of people using the same laptop with Windows who have the same problem. In some cases a bios upgrade fixed it, in others not. I tried to do this but it requires using an .exe file, and though I could do this with both wine and dosemu I couldn't obtain a suitable iso file to do the upgrade. (Also, I was a little afraid of ending up with an unbootable machine, which a few people report as happening.) BUT I have found that by unloading and reloading the video module (and/or the radeon module) I can sometimes obtain the requisite backlight file in /sys/devices/virtual .., after which the screen either becomes bright automatically or I can do it manually. So it seems to be something to do with the order in which the modules are loaded, though I can't figure out what. The effect is unpredictable - sometimes it works, sometimes not. Anthony -- Anthony Campbell - a...@acampbell.org.uk Microsoft-free zone - Using Debian GNU/Linux http://www.acampbell.org.uk - sample my ebooks at http://www.smashwords.com/profile/view/acampbell -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110424094926.ga2...@acampbell.org.uk
Re: Backlight mystery - anyone shed light? some progress
On Sun, Apr 24, 2011 at 5:49 AM, Anthony Campbell a...@acampbell.org.uk wrote: Thanks, Camaleon. I found a lot of people using the same laptop with Windows who have the same problem. In some cases a bios upgrade fixed it, in others not. I tried to do this but it requires using an .exe file, and though I could do this with both wine and dosemu I couldn't obtain a suitable iso file to do the upgrade. (Also, I was a little afraid of ending up with an unbootable machine, which a few people report as happening.) don't run an exe bios upgrade inside of wine, dosemu, or any other vm. you might be able to extract the exe and find some binary file and then there might be some sort of linux utility to write that. however, when you upgrade a bios, don't do anything weird because the only way (that i know of) to test it is to reboot. well, if something isn't written correctly and you try to reboot, you'll know because the machine won't post. at that point there are three choices: replace the machine, replace the bios (might require soldering / desoldering), or rewriting the firmware onto the bios (might not be possible depending on whether you can find schematics for a writer for that type of chip and software). most people (including me) shed a tear and go shopping for a new computer at this point. though, if your laptop is under warranty, you could call them and make sure they'll replace the board if it doesn't post, once you confirm they will, go and have fun :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktikq6bpwf-p8+k6z0cesae4gofb...@mail.gmail.com
Re: Backlight mystery - anyone shed light? some progress
On 24 Apr 2011, shawn wilson wrote: On Sun, Apr 24, 2011 at 5:49 AM, Anthony Campbell a...@acampbell.org.uk wrote: Thanks, Camaleon. I found a lot of people using the same laptop with Windows who have the same problem. In some cases a bios upgrade fixed it, in others not. I tried to do this but it requires using an .exe file, and though I could do this with both wine and dosemu I couldn't obtain a suitable iso file to do the upgrade. (Also, I was a little afraid of ending up with an unbootable machine, which a few people report as happening.) don't run an exe bios upgrade inside of wine, dosemu, or any other vm. you might be able to extract the exe and find some binary file and then there might be some sort of linux utility to write that. however, when you upgrade a bios, don't do anything weird because the only way (that i know of) to test it is to reboot. well, if something isn't written correctly and you try to reboot, you'll know because the machine won't post. at that point there are three choices: replace the machine, replace the bios (might require soldering / desoldering), or rewriting the firmware onto the bios (might not be possible depending on whether you can find schematics for a writer for that type of chip and software). most people (including me) shed a tear and go shopping for a new computer at this point. though, if your laptop is under warranty, you could call them and make sure they'll replace the board if it doesn't post, once you confirm they will, go and have fun :) Thanks - this is pretty much what I thought myself. The laptop is out of warranty so I think I shall soldier on trying to figure out how to make it work by some combination of module loading, since sometimes that succeeds. Failing that, I shall have to junk it. Anthony -- Anthony Campbell - a...@acampbell.org.uk Microsoft-free zone - Using Debian GNU/Linux http://www.acampbell.org.uk - sample my ebooks at http://www.smashwords.com/profile/view/acampbell -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110424115800.gb2...@acampbell.org.uk
Re: Backlight mystery - anyone shed light? some progress
On Sun, 24 Apr 2011 10:49:26 +0100, Anthony Campbell wrote: On 23 Apr 2011, Camaleón wrote: Also, check for a BIOS update, most of these ACPI things are usually fixed after updating to the latest BIOS. Thanks, Camaleon. I found a lot of people using the same laptop with Windows who have the same problem. In some cases a bios upgrade fixed it, in others not. I tried to do this but it requires using an .exe file, and though I could do this with both wine and dosemu I couldn't obtain a suitable iso file to do the upgrade. (Also, I was a little afraid of ending up with an unbootable machine, which a few people report as happening.) Don't be afraid of a BIOS update. Laptops need this piece of code to be updated more often than desktops machines due to buggy firmware and notebook's embedded nature. What happens here is that manufacturers do not always provide a utility to extract the update file in order you can put it into a USB/CD-ROM to run the update and sadly the complete procedure needs to be done in a windows environment. (That's one of the reasons why it is a good idea to do not remove the windows partition although you don't use it on your day work :-/) BUT I have found that by unloading and reloading the video module (and/or the radeon module) I can sometimes obtain the requisite backlight file in /sys/devices/virtual .., after which the screen either becomes bright automatically or I can do it manually. So it seems to be something to do with the order in which the modules are loaded, though I can't figure out what. The effect is unpredictable - sometimes it works, sometimes not. If you can wait with that bypass, msot sure is that any kernel update will solve the problem as you seemed to experience with 2.6.37 and 2.6.38 branches. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.04.24.11.58...@gmail.com
Re: Backlight mystery - anyone shed light? some progress
On 24 Apr 2011, Camaleón wrote: On Sun, 24 Apr 2011 10:49:26 +0100, Anthony Campbell wrote: On 23 Apr 2011, Camaleón wrote: Also, check for a BIOS update, most of these ACPI things are usually fixed after updating to the latest BIOS. Thanks, Camaleon. I found a lot of people using the same laptop with Windows who have the same problem. In some cases a bios upgrade fixed it, in others not. I tried to do this but it requires using an .exe file, and though I could do this with both wine and dosemu I couldn't obtain a suitable iso file to do the upgrade. (Also, I was a little afraid of ending up with an unbootable machine, which a few people report as happening.) Don't be afraid of a BIOS update. Laptops need this piece of code to be updated more often than desktops machines due to buggy firmware and notebook's embedded nature. What happens here is that manufacturers do not always provide a utility to extract the update file in order you can put it into a USB/CD-ROM to run the update and sadly the complete procedure needs to be done in a windows environment. (That's one of the reasons why it is a good idea to do not remove the windows partition although you don't use it on your day work :-/) Yes, I was keeping it for that reason, but unfortunately it has ceased to work for some reason. BUT I have found that by unloading and reloading the video module (and/or the radeon module) I can sometimes obtain the requisite backlight file in /sys/devices/virtual .., after which the screen either becomes bright automatically or I can do it manually. So it seems to be something to do with the order in which the modules are loaded, though I can't figure out what. The effect is unpredictable - sometimes it works, sometimes not. If you can wait with that bypass, msot sure is that any kernel update will solve the problem as you seemed to experience with 2.6.37 and 2.6.38 branches. There was an upgrade of 2.6.38 in unstable today and also an upgrade of udev. Unfortunately I now can't even get 2.6.37 to work reliably, though it did after a bit of fiddling. It's just hit and miss. I've come to the conclusion I hate all laptops! -- Anthony Campbell - a...@acampbell.org.uk Microsoft-free zone - Using Debian GNU/Linux http://www.acampbell.org.uk - sample my ebooks at http://www.smashwords.com/profile/view/acampbell -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110424121537.gc2...@acampbell.org.uk
Re: Backlight mystery - anyone shed light? some progress
On 24 Apr 2011, Anthony Campbell wrote: On 24 Apr 2011, Camaleón wrote: Well, it's beginning to look as if it was a hardware problem all along. The Windows partition disappeared and the backlight began to work perfectly. I decided to do a reinstall in the former Windows partition. Everything seemed to go off correctly but when I came to reboot into Debian I got Nonsystem Disk or disk failure: Replace and strike any key when ready. I think there must have been some hardware failure. Anthony -- Anthony Campbell - a...@acampbell.org.uk Microsoft-free zone - Using Debian GNU/Linux http://www.acampbell.org.uk - sample my ebooks at http://www.smashwords.com/profile/view/acampbell -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110424211012.gd2...@acampbell.org.uk
Re: Backlight mystery - anyone shed light? some progress
On Sun, Apr 24, 2011 at 5:10 PM, Anthony Campbell a...@acampbell.org.uk wrote: On 24 Apr 2011, Anthony Campbell wrote: On 24 Apr 2011, Camaleón wrote: Well, it's beginning to look as if it was a hardware problem all along. The Windows partition disappeared and the backlight began to work perfectly. I decided to do a reinstall in the former Windows partition. Everything seemed to go off correctly but when I came to reboot into Debian I got Nonsystem Disk or disk failure: Replace and strike any key when ready. I think there must have been some hardware failure. that's your mbr talking to you. don't think that's hardware 'failure'. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=yiQ4iErQ4d=wgw-wbvyst9l5...@mail.gmail.com
Re: Backlight mystery - anyone shed light?
On 22 Apr 2011, shawn wilson wrote: 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. I'm not too sure about how to do those things. Any pointers? 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. Yes, I thought of that, but I've searched through all of /sys without coming across anything relevant. -- Anthony Campbell - a...@acampbell.org.uk Microsoft-free zone - Using Debian GNU/Linux http://www.acampbell.org.uk - sample my ebooks at http://www.smashwords.com/profile/view/acampbell -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110423074318.gl9...@acampbell.org.uk
Re: Backlight mystery - anyone shed light?
On 22 Apr 2011, Camaleón wrote: On Tue, 19 Apr 2011 17:14:35 +0100, Anthony Campbell wrote: My HP laptop tends to boot with a dim screen. (...) Hum... some of the new HP notebooks have a sensor that automatically adjusts the brightness of the screen depending on the ambient light. This can be turned off in windows but I dunno if there is such utility for linux :-? What video driver are you loading? Greetings, -- Camaleón This is a laptop (6735s) and is over a year old so not very new. I don't think it has that feature. It uses the radeon driver. Anthony -- Anthony Campbell - a...@acampbell.org.uk Microsoft-free zone - Using Debian GNU/Linux http://www.acampbell.org.uk - sample my ebooks at http://www.smashwords.com/profile/view/acampbell -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110423075007.gm9...@acampbell.org.uk
Re: Backlight mystery - anyone shed light?
On Sat, 23 Apr 2011 08:50:07 +0100, Anthony Campbell wrote: On 22 Apr 2011, Camaleón wrote: On Tue, 19 Apr 2011 17:14:35 +0100, Anthony Campbell wrote: My HP laptop tends to boot with a dim screen. (...) Hum... some of the new HP notebooks have a sensor that automatically adjusts the brightness of the screen depending on the ambient light. This can be turned off in windows but I dunno if there is such utility for linux :-? What video driver are you loading? This is a laptop (6735s) and is over a year old so not very new. I don't think it has that feature. It uses the radeon driver. You will find out in the BIOS screen. If the feature is there, there should be an option to toggle it on/off under system configuration menu/ buit-in options Also, check for a BIOS update, most of these ACPI things are usually fixed after updating to the latest BIOS. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.04.23.10.53...@gmail.com
Re: Backlight mystery - anyone shed light?
I'm taking a stab in the dark here (pun intended)... do you happen to have a /run directory? I had some issues with devices not being detected on boot recently which turned out to be related to udev attempting to read from /run. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621036 In my case I removed /run and everything was back to normal. If you have no /run then sorry for the dull response :)
Re: Backlight mystery - anyone shed light?
On Tue, Apr 19, 2011 at 12:14 PM, Anthony Campbell a...@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) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTikSw=hysu2gaup0mqflbtsicf9...@mail.gmail.com
Re: Backlight mystery - anyone shed light?
On 22 Apr 2011, James Robertson wrote: I'm taking a stab in the dark here (pun intended)... do you happen to have a /run directory? I had some issues with devices not being detected on boot recently which turned out to be related to udev attempting to read from /run. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621036 In my case I removed /run and everything was back to normal. A If you have no /run then sorry for the dull response :) Thanks for the suggestion, but unfortunately I don't have /run so it isn't that in my case. -- Anthony Campbell - a...@acampbell.org.uk Microsoft-free zone - Using Debian GNU/Linux http://www.acampbell.org.uk - sample my ebooks at http://www.smashwords.com/profile/view/acampbell -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110422145213.gj9...@acampbell.org.uk
Re: Backlight mystery - anyone shed light?
On Tue, 19 Apr 2011 17:14:35 +0100, Anthony Campbell wrote: My HP laptop tends to boot with a dim screen. (...) Hum... some of the new HP notebooks have a sensor that automatically adjusts the brightness of the screen depending on the ambient light. This can be turned off in windows but I dunno if there is such utility for linux :-? What video driver are you loading? Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.04.22.15.02...@gmail.com
Re: Backlight mystery - anyone shed light?
On 22 Apr 2011, shawn wilson wrote: On Tue, Apr 19, 2011 at 12:14 PM, Anthony Campbell a...@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. Anthony -- Anthony Campbell - a...@acampbell.org.uk Microsoft-free zone - Using Debian GNU/Linux http://www.acampbell.org.uk - sample my ebooks at http://www.smashwords.com/profile/view/acampbell -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110422150550.gk9...@acampbell.org.uk
Re: Backlight mystery - anyone shed light?
On Apr 22, 2011 11:06 AM, Anthony Campbell a...@acampbell.org.uk wrote: On 22 Apr 2011, shawn wilson wrote: On Tue, Apr 19, 2011 at 12:14 PM, Anthony Campbell a...@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.
Backlight mystery - anyone shed light?
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. 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. 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. 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 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, Anthony -- Anthony Campbell - a...@acampbell.org.uk Microsoft-free zone - Using Debian GNU/Linux http://www.acampbell.org.uk - sample my ebooks at http://www.smashwords.com/profile/view/acampbell -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110419161435.ga6...@acampbell.org.uk
