acpi-support lid event delay and unstable backlight

Bug #322615 reported by Dean Mellas
2
Affects Status Importance Assigned to Milestone
acpi-support (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: acpi-support

Two updates to acpi-support were accepted and installed, recently. After the first, acpi-support_0.114-0intrepid1_i386.deb - the lid event is finally recognized on my HP 6140 Business Laptop, BUT only about 3 or 4 minutes AFTER the first lid event occurs, THEN it behaves normally until a reboot, when the first event delay is repeated.

If the first event is opening the lid (i.e., it was powered-on with the lid closed, and allowed to boot that way) then all seems normal IF the first (other) lid event is after the necessary delay.

After the second update, acpi-support_0.114-0intrepid2_i386.deb - The above noted problem persists and I also noticed instability with the screen backlight on battery power, but that may be the first time since either update that I used the battery. The screen soon became too dark, and wouldn't allow me to adjust the brightness, either by normal activity or by using the brightness controls. I tried System -> Preferences -> Power Management [On Battery Power] and disabled both Reduce backlight brightness and Dim display when idle. It seemed to require disabling BOTH before I could keep the display bright. Without that, the brightness seemed to change erratically and without reference to any kind of activity, including the use of the brightness controls.

Revision history for this message
Andreas Schildbach (schildbach) wrote :

Your "unstable backlight" problem is likely a duplicate of bug 313231.

Revision history for this message
Dean Mellas (dmellas) wrote :

I don't think my bug is a duplicate, namely because I had the trouble BEFORE the linux-image-2.6.27-11-generic update - on my system. I was also noticing the date on the bug report you referenced because the timing doesn't match the way the updates came in for me. I'm guessing that the reporter of that other bug is doing more kernel updates because I only get the odd numbered revisions and I went from kernel 2.6.27-9-generic to -11 after I reported the trouble. It was definitely the first acpi-support_0.114-0 that made my laptop recognize the lid event at all (but always after a 4 minute delay from the first event). And that delay remains to this day (February 8th) with all updates, now including kernel -11 (and I have my reported work-around for the backlight problems that came in the set of updates that included acpi-support_0.114-0 intrepid1 and intrepid2).

Revision history for this message
Dean Mellas (dmellas) wrote :

The delay in recognizing the laptop lid event for my HP nc6140 continues in Jaunty (first reported in Intrepid). It still requires a long delay before the event is handled. Currently I use only "blank screen" on the event, and the screen will blank, for a moment, much, much later, as I continue working. I wonder what would happen if the event handler selection were changed to "shutdown" and someone continued working after they noticed the system did not shut down (right away)? Perhaps, several minutes later, they would be surprised to be booted-off in the middle of their work? Hopefully, they might be saved by the new countdown clock, if they are looking, and that may not even apply to the acpi events. Anyway, I will have this system for testing only a little while longer. The replacement may or may not experience a similar problem as the new hardware will be quite different.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.