Re: Radeon drm: dpms backlight problem / question / bug?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 10, 2010 at 12:10 PM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote:
> 2010/11/6 Prof. Dr. Klaus Kusche <klaus.kusche@xxxxxxxxxxxxxxx>:
>> On 2010-11-02 08:20, Michel Dänzer wrote:
>>>
>>> On Mon, 2010-11-01 at 16:09 +0100, Prof. Dr. Klaus Kusche wrote:
>>>>
>>>> On my Dell Precision M6500, backlight power switching does not work,
>>>> neither by using bl_power in /sys/backlight/...
>>>
>>> Please provide the full path of the file you're using.
>>>
>>>> nor by using DPMS:
>>>> * Any changes of bl_power are simply and silently ignored
>>>>    (no effect, except that brightness is set to minimum),
>>>>    although brightness tuning works fine
>>>>    (in other words: Both the generic ACPI BIOS driver and the in-kernel
>>>>    Dell laptop backlight driver can control backlight brightness,
>>>>    but not backlight power).
>>>> * If DPMS becomes active, the screen contents on the internal display
>>>>    slowly becomes garbled or fades away (so video output drivers
>>>>    seem to be off), but the backlight remains on
>>>>    (which is very bad for battery power).
>>>>    The external screen (on display port) behaves even worse:
>>>>    It enters energy saving mode (backlight off) and immediately wakes up
>>>>    again, continuously cycling the backlight power every few seconds.
>>>>
>>>> Another problem which optically looks the same:
>>>> Zapping the X server (Xorg 1.9.1, radeon 6.13.2) with Ctrl-Alt-Bksp
>>>> leaves the system in an undefined state:
>>>> * Similar to DPMS, the display fades away or gets garbled
>>>>    (video output off), but the backlight remains on.
>>>> * It does not switch to the text console automatically,
>>>>    nor is it possible to switch manually with Ctrl-Alt-Fn.
>>>>
>>>> Configuration:
>>>> * Kernel 2.6.35.7-grsec
>>>> * Radeon DRM with KMS
>>>> * Radeon framebuffer with backlight control enabled
>>>> * The Radeon chip is a JUNIPER 0x1002:0x68A0,
>>>>    the kernel should contain all the microcode needed for it.
>>>> * The displays are LCD1: INTERNAL_UNIPHY and DFP1: INTERNAL_UNIPHY1
>>>
>>> Please provide the full Xorg.0.log file and dmesg output.
>>
>> I've sent the full logs on Nov 2nd.
>> Did they arrive?
>> Did they provide any insight?
>>
>> Anything else I can do / try / provide?
>>
>
> I have some ideas, but I won't be able to look at this until next week.

Try these patches:
http://lists.freedesktop.org/archives/dri-devel/2010-November/005506.html
http://lists.freedesktop.org/archives/dri-devel/2010-November/005507.html

Alex

>
> Alex
>
>> Many thanks in advance for your help!
>>
>> --
>> Prof. Dr. Klaus Kusche
>> Private address: Rainstraße 9/1, 88316 Isny, Germany
>> +49 7562 6211377 Klaus.Kusche@xxxxxxxxxxxxxxx http://www.computerix.info
>> Office address: NTA Isny gGmbH, Seidenstraße 12-35, 88316 Isny, Germany
>> +49 7562 9707 36 kusche@xxxxxxxxxxx http://www.nta-isny.de
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@xxxxxxxxxxxxxxxxxxxxx
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux