Mailinglist Archive: radeonhd (408 mails)

[Egbert Eich <eich@xxxxxxx>]

Replying to this even though risking to generate another broken email.
You'll have to bear with me until I can switch mailer.

Rafa? Mi?ecki writes:
> 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.

... and will trigger additional bug reports saying:
'my backlight control isn't working!'.

> 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.

... unfortunately, yes. Lemme try and add the AtomBIOS variant and see
if this will work for you. (In fact you could try if this would work for
you by enabling AtomBIOS with the "UseAtomBIOS" option.

> 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

Oh, ok, you've got a VAIO - my sympathy.

> 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?

We've already got a PCI subvendor ID based quirks list. We could add this
to the flags section there.

> Do you have some other ideas? Some comments to these proposed? I think
> 3rd solution is the best one, but not sure about indetification.

So far I cannot come up with anything better ...

Cheers,
        Egbert.
-- 
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx