Mailinglist Archive: radeonhd (408 mails)

[Alex Deucher <alexdeucher@xxxxxxxxx>]

2009/6/30 Rafał Miłecki <zajec5@xxxxxxxxx>:
> Thank you for explainations, if I'm right we have 3 solutions here:
>
> 1) Always create _Backlight property for PANEL
>
> This will work in some cases, won't work when backlight is controled
> by something else that on-chip controller. Second case leads just to
> exposing not working property. Won't cause crashes, instability, just
> a little misinformation and... mess (?) in randr.
>
> 2) Create _Backlight only when we are sure it will work and add option
> "ForceBlControl"
>
> Quite nice, clean solution. The problem is that this is very not
> user-friendly. Personally I really want Linux to be system "for
> everyone", not needing hacking configuration files.
>
> 3) Create _Backlight when we are sure it will work, store list of
> additional machines and add option "ForceBlControl"
>
> This would lead to creating database of machines where we can't detect
> ability of controlling backlight, but where it works (like mine Sony
> VAIO). Option "ForceBlControl" would allow test radeonhd's mechanism
> on machines not present on list (users could report it's working for
> them, and we could then add that machine).
> The problem may be identification on machine. We can't use pci id, as
> the same card may be used in different machines with differenc
> backlight control. I thought of using mechanism of s2ram, can we do
> that?
>
>
> Do you have some other ideas? Some comments to these proposed? I think
> 3rd solution is the best one, but not sure about indetification.

Arguably the best solution is to use the acpi backlight control
methods rather than exposing a randr property as they have the best
chance of working on every machine regardless of how the backlight is
wired up.

Alex
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx