Bug 24617 - Wrong backlight level detection using AtomBIOS
Summary: Wrong backlight level detection using AtomBIOS
Status: RESOLVED WONTFIX
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-19 06:16 UTC by Rafał Miłecki
Modified: 2011-10-17 16:07 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Add RHD_CARD_FLAG_FORCEBL flag forcing on chip backlight control usage (3.43 KB, patch)
2009-11-17 08:38 UTC, Rafał Miłecki
no flags Details | Splinter Review

Description Rafał Miłecki 2009-10-19 06:16:10 UTC
It's bug in AtomBIOS or our reading AtomBIOS answer. My backlight is controlled by GPU so there are two important properties to check:
1) Is backlight control turned on
2) What level is used

After booting backlight control is turned *off* and backlight value set to 0. Of course backlight level doesn't matter in that case, as backlight control is disabled. Backlight level is max in result.

AtomBIOS ignores fact that backlight control is turned off, just reports backlight level (or not AtomBIOS, but out AtomBIOS parser hopefully).

So after booting I have max backlight level and this: 

PANEL connected 1600x900+0+0 (normal left inverted right x axis y axis) 423mm x 238mm
        Backlight: 0 (0x00000000)       range:  (0,255)
        _PanningArea:
        _OutputNumber: 2 (0x00000002)
        ConnectorNumber: 2 (0x00000002)
        ConnectorType:  Panel
        SignalFormat:   LVDS
                supported: LVDS
Comment 1 Rafał Miłecki 2009-10-19 06:24:30 UTC
This seems to be fixed by 392a13923eb4d44a8bdb204922230e126b188fae, but this commit introduces new bug to backlight control #24592.

Just in case I reported that as two separated issues.
Comment 2 Rafał Miłecki 2009-10-19 09:25:18 UTC
(In reply to comment #1)
> This seems to be fixed by 392a13923eb4d44a8bdb204922230e126b188fae, but this
> commit introduces new bug to backlight control #24592.

That was not it. Bug #24592 is now fixed, but this is still valid.
Comment 3 Egbert Eich 2009-10-20 02:05:56 UTC
We can't. With AtomBIOS we can only do so much - if AtomBIOS is lying to us regarding backlight there is not much we can do. This is why we use AtomBIOS as the very last resort after both direct HW access and ACPI have failed.
The value read back should be OK after you have first set it.
Of course we can set a fixed value if AtomBIOS reports 0 - this however will trigger other bug reports. 
Comment 4 Rafał Miłecki 2009-11-17 08:38:49 UTC
Created attachment 31263 [details] [review]
Add RHD_CARD_FLAG_FORCEBL flag forcing on chip backlight control usage

Then I'd like to propose this patch which introduces new flag for devices quirks.
Comment 5 Jeremy Huddleston Sequoia 2011-10-16 15:59:06 UTC
Does this issue occur with the preferred ati driver (xf86-vide-ati)?  If so, please move this to the Driver/Radeon component.  

Development of radeonhd has pretty much halted and development focus is on the ati driver.  Please see http://www.x.org/wiki/radeonhd

If the issue does not exist in the ati driver (or if there is no response to this message), this bug will be closed as WONTFIX unless someone contributes a patch.
Comment 6 Rafał Miłecki 2011-10-17 14:34:10 UTC
(In reply to comment #5)
> Does this issue occur with the preferred ati driver (xf86-vide-ati)?  If so,
> please move this to the Driver/Radeon component.  

How does radeon report backlight level according to you?
Comment 7 Alex Deucher 2011-10-17 16:07:32 UTC
Not relevant for xf86-video-ati.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.