[Solved] Cannot adjust screen brightness.

[kedaha]

I'd be interested to read any comments about an issue with this old and problematic graphic card: screen brightness.

Code: Select all

Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03)

So, I've Installed wheezy - Gnome 3, classic on this old laptop and it works surprisingly well - no freezes or booting issues which occurred after installing lenny many moons ago.
I might mention that I can only boot using the nomodeset kernel parameter which I've added to /etc/default/grub.

Code: Select all

# cat /etc/default/grub |grep GRUB_CMDLINE
GRUB_CMDLINE_LINUX_DEFAULT="quiet nomodeset acpi-osi=linux acpi_backlight=vendor"
GRUB_CMDLINE_LINUX="initrd=/install/gtk/initrd.gz"

I added acpi-osi=linux acpi_backlight=vendor to see if it would help but apparently not.
No /etc/X11/xorg.conf required.
Acceleration is working.

Code: Select all

$  glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x209)
    GL_NV_conditional_render, GL_AMD_draw_buffers_blend, 

However, screen brightness cannot be adjusted.

Code: Select all

$ dmesg |grep -i bug
[    0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 7MB of RAM.
[    0.096232] [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
[    0.098475] PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug
[    0.099788] * The chipset may have PM-Timer Bug. Due to workarounds for a bug,
[    0.099791] * this bug, please use "acpi_pm_good" to disable the workaround
[    1.493406] ehci_hcd 0000:00:1d.7: debug port 1

Regarding the Firmware Bug, the solution proposed in dsdt-editing-put-an-end-to-your-acpi-woes, is to install iasl, extract the DSDT, recompile the file & debug it and recompile the kernel - rather a time-consuming process which I would prefer to avoid if there's a workaround or perhaps the Firmware Bug is not present in a later kernel?
Any comments would be very much appreciated. Thank you for reading.

[kedaha]

I have found the solution by trial and error having read how-fix-your-buggy-dsdt. No need to recompile the kernel after all but, in this case, just add the following Windows acpi parameter to /etc/default/grub.

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="quiet i915.modeset=0 acpi_os_name="Microsoft Windows ME: Millenium Edition""

I also changed nomodeset to i915.modeset=0.
I can now adjust brightness using the FN Function key and F7 to increase brightness and F8 to reduce it.
Edit. Just to add that the Brookdale froze while I was examining the brightness issue so, for maximum stability - since the laptop is for an unsavvy user - I decided to disable the intel driver and enable the vesa driver instead.

[llivv]

a couple of notes from the cheap seats ..
845 was intels first go at ddr,
so no surprises that it gives issues...
845g(x) chipsets along with 830g(x) and some 815x chipsets only have 8 MB of shared ram for video.
It gets real tricky to get KMS to switch from the intelfb (or the machines default fb ) to the intel driver properly with that little video ram.
And the dmesg errors are usually pointing at something only the upstream devs know much, if anything at all about.

[kedaha]

845g(x) chipsets along with 830g(x) and some 815x chipsets only have 8 MB of shared ram for video.
It gets real tricky to get KMS to switch from the intelfb (or the machines default fb ) to the intel driver properly with that little video ram.

Indeed; I can only boot wheezy with either nomodeset or i915.modeset=0
I posted about installing lenny on the laptop in viewtopic.php?f=17&t=52197 when I spent hours on trying different /etc/X11/xorg.conf options. (By the way, the file I posted there didn't work in wheezy), and it seemed in the end I got it right then because the freezes stopped; however, there were other issues; booting was very slow and the laptop owner went and bought a printer which I couldn't get to work in lenny without spending more time than I wished to so I resorted to re-installing Ubunto 9.04. Although it was slow to boot (and sometimes not at all), it worked OK with a vesa driver and the printer worked.

And the dmesg errors are usually pointing at something only the upstream devs know much, if anything at all about.

Apart from the question whether to use the intel driver, with possible freezes or the stable vesa driver - solving the screen brightness problem, in this case by adding the "acpi_os_name="Microsoft Windows ME: Millenium Edition" parameter is OK - but I went through the steps given in dsdt-editing-put-an-end-to-your-acpi-woes, and iasl threw out a number of ACPI errors, which I think may be the cause of slow booting. So, looking for the solution to the problem of screen brightness has led to a possible fix for another. Maybe I'll try and fix the slow boot issue now that I can look at the screen without getting eyestrain!

[llivv]

Iviewtopic.php?f=17&t=52197 when I spent hours on trying different /etc/X11/xorg.conf options. (By the way, the file I posted there didn't work in wheezy),

I see possible issues with mixed accelmethod options

Code: Select all

Section "Device"
   Identifier   "Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device" #Configured Video Device
        Driver          "intel"
        BusID           "PCI:0:2:0"
        Option          "AccelMethod" "UXA"
        Option          "EXAOptimizeMigration"  "true" #added by kedaha
        Option          "MigrationHeuristic"  "greedy" #added by kedaha
        Option          "Tiling"   "false" #added by kedaha
        VideoRam        130560
        # Add this option :
        Option "XAANoOffscreenPixmaps" "true"
EndSection

( but without dmesg and Xorg.0.log to confirm they are only suspicions ). -- Lenny comments by refracta are spot on (imo) for a branded machine, but I've never heard of the brand mentioned and OEM's have been known to pull some strange stunts with software hardware and bios ( in that order ).

dsdt-editing-put-an-end-to-your-acpi-woes, and iasl

This is currently beyond my paygrade. I get some of it but only some

Because humans just aren't sweet enough

last paragraph

clean DSDT … atleast till the next kernel update!

And that doesn't even take into account the other upgrades. ie wheezy and kms to name a couple.

[kedaha]

dsdt-editing-put-an-end-to-your-acpi-woes, and iasl

This is currently beyond my paygrade.

I've been looking at the errors shown below; they're interesting so I'll post them just for completeness since I mentioned the intel compiler.

# aptitude install iasl
# cat /sys/firmware/acpi/tables/DSDT > dsdt.aml
# chmod 666 dsdt.aml
# exit
$ iasl -tc dsdt.aml

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20100528 [Jul 2 2010]
Copyright (c) 2000 - 2010 Intel Corporation
Supports ACPI Specification Revision 4.0a

Non-ascii input file - dsdt.aml
user@localhost:~$ iasl -d dsdt.aml

Intel ACPI Component Architecture
AML Disassembler version 20100528 [Jul 2 2010]
Copyright (c) 2000 - 2010 Intel Corporation
Supports ACPI Specification Revision 4.0a

Loading Acpi table from file dsdt.aml
Acpi table [DSDT] successfully installed and loaded
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
.................................................................................................................................................................................................................................................................
Parsing completed
Disassembly completed, written to "dsdt.dsl"[/code]
$ iasl -tc dsdt.dsl

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20100528 [Jul 2 2010]
Copyright (c) 2000 - 2010 Intel Corporation
Supports ACPI Specification Revision 4.0a

dsdt.dsl 1361: 0x00080000, // Length
Error 4117 - Length is larger than Min/Max window ^

dsdt.dsl 1367: 0x00080000, // Length
Error 4117 - Length is larger than Min/Max window ^

dsdt.dsl 1373: 0x00DFFC00, // Length
Error 4117 - Length is larger than Min/Max window ^

dsdt.dsl 2962: Store (0x1F, P378)
Warning 1100 - Statement is unreachable ^

dsdt.dsl 2967: Store (0x0F, P378)
Warning 1100 - Statement is unreachable ^

dsdt.dsl 3552: 0x00000000, // Length
Error 4122 - ^ Invalid combination of Length and Min/Max fixed flags

dsdt.dsl 3559: 0x00000000, // Length
Error 4122 - ^ Invalid combination of Length and Min/Max fixed flags

ASL Input: dsdt.dsl - 3788 lines, 132191 bytes, 1588 keywords
Compilation complete. 5 Errors, 2 Warnings, 0 Remarks, 47 Optimizations


$ iasl -tc dsdt.dsl

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20100528 [Jul 2 2010]
Copyright (c) 2000 - 2010 Intel Corporation
Supports ACPI Specification Revision 4.0a

dsdt.dsl 1361: 0x00080000, // Length
Error 4117 - Length is larger than Min/Max window ^

dsdt.dsl 1367: 0x00080000, // Length
Error 4117 - Length is larger than Min/Max window ^

dsdt.dsl 1373: 0x00DFFC00, // Length
Error 4117 - Length is larger than Min/Max window ^

dsdt.dsl 2962: Store (0x1F, P378)
Warning 1100 - Statement is unreachable ^

dsdt.dsl 2967: Store (0x0F, P378)
Warning 1100 - Statement is unreachable ^

dsdt.dsl 3552: 0x00000000, // Length
Error 4122 - ^ Invalid combination of Length and Min/Max fixed flags

dsdt.dsl 3559: 0x00000000, // Length
Error 4122 - ^ Invalid combination of Length and Min/Max fixed flags

ASL Input: dsdt.dsl - 3788 lines, 132191 bytes, 1588 keywords
Compilation complete. 5 Errors, 2 Warnings, 0 Remarks, 47 Optimizations

Line 3552 shows
DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite,
0x00000000, // Granularity
0x00000000, // Range Minimum
0x00000000, // Range Maximum
0x00000000, // Translation Offset
0x00000000, // Length

Looking at error line 1361, I see:
Memory32 (ReadOnly,
0xFFE80000, // Range Minimum
0xFFE80000, // Range Maximum
0x00000000, // Alignment
0x00080000, // Length
)[/code]
Line 1367 is similar:
Memory32 (ReadOnly,
0xFFF80000, // Range Minimum
0xFFF80000, // Range Maximum
0x00000000, // Alignment
0x00080000, // Length
)
Line 1337 shows:
Memory32 (ReadOnly,
0xFEE00400, // Range Minimum
0xFEE00400, // Range Maximum
0x00000000, // Alignment
0x00DFFC00, // Length
)
And finally line 3552 shows:
DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite,
0x00000000, // Granularity
0x00000000, // Range Minimum
0x00000000, // Range Maximum
0x00000000, // Translation Offset
0x00000000, // Length

It doesn't look fixable; the range minimums and maximums are identical.

I get some of it but only some

Because humans just aren't sweet enough

last paragraph

clean DSDT … atleast till the next kernel update!

And that doesn't even take into account the other upgrades. ie wheezy and kms to name a couple.

It doesn't look like I can get a clean DSDT but, with the vesa driver, wheezy works very well on the hardware.

[stevesr0]

To kedaha: Although you marked this "solved", I thought you might be interested in the following experience and comments.

This sounds like a problem similar to that discussed at: http://www.debianuserforums.org/viewtop ... 3&start=60
(which appears to be the same one I am experiencing).

This is a ?somewhat well known bug between KMS and the intel i915 graphic driver, which causes the backlight to be shut off when the system attempts to adjust the video resolution on booting. The screen becomes dark and apparently inactive with a visible prompt.

The poster (Jay Abbott) noted that the apparently blank screen was just very dark. He was able to use a strong flashlight to determine that. He described how he was able to work around the problem until he was able to implement a permanent fix. He described two ways: (a) editing grub to add "i915.modeset=0" or (b) blindly login and launching Xwindows.

After reading his experience, I have been able to deal with it by the blind login technique.

After submitting a bug report to the intel linux graphics team, they produced a patch and he was able to compile a patched kernel which no longer produces a problem.

Your solution, using a Windows Millenium modification in Grub, seems much easier than a kernel compile (I haven't compiled any kernels yet). How did you come to try that solution?

I will try adding that at boot and see if it works on my laptop (Fujitsu T4220, with an intel 965GM integrated chipset).

P.S. In looking for this thread, I noted a couple of other recent threads about failure to change resolution, and I wonder whether they also represent examples of the same bug.

[kedaha]

@ stevesr0
Thanks for your reply about a similar issue; most interesting.
I looked at quite a lot of documentation about but, if I remember aright, the exact Windows acpi parameter, which I added to /etc/default/grub, was found in the file generated by iasl, the Intel ASL compiler/decompiler. I'd forgotten that the laptop originally ran Windows Millenium and tried the option, having seen it there, on the off-chance and it worked. I returned the laptop to its owner who is very pleased with it so I was unable to try and get it to work with the intel driver - with graphics acceleration - but without freezes.
Just adding a grub option is certainly preferable to compiling a customised kernel so I'd exhaust the simpler options first and also try the kernel backported from jessie.

[stevesr0]

@ kedaha

Thanks for response.

I agree that a grub edit is far simpler than recompiling a kernel.

So far, I haven't tried the Millenium edit or anything else, because the blind login works. I have come to consider that as a security feature <g>.

I should say that sometimes the boot successfully completes to a visible login screen (about 1 out of 4 boots).