Re: [radeonhd] [PATCH] Somehow /force/ backlight control

newer
Re: AtomDis: weird bit sum for...

older
AtomDis:master: 1 commit(s)

Egbert Eich

29 Jun 2009 29 Jun '09

16:08

Rafa? Mi?ecki writes:

...

Currently we don't try to control backlight after detecting (RHDRegRead(Output, RV620_LVTMA_BL_MOD_CNTL) & LVTMA_BL_MOD_EN) == 0

This assumption is quite wrong, because in some (many?) cases we can just change this one bit and control backlight without problem. Confirmed to work on M82==RV620.

This is possible but there is no guarantee. It could also be controlled by some OEM specific mechanism. In those cases we cannot control backlight, if at all it can be controlled over ACPI. To not expose a backlight property if we cannot control it anyway I had decided to use this check. We could fall back to AtomBIOS controlled backlight in cases where we are not sure as this might be programmed correctly for the system in question - however to implement this would require some extra work as in the hard coded cases the needed data structures have not been set up. Cheers, Egbert. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Show replies by date

Rafał Miłecki

29 Jun 29 Jun

17:52

New subject: [PATCH] Somehow /force/ backlight control

W dniu 29 czerwca 2009 18:08 użytkownik Egbert Eich napisał:

...

Rafa? Mi?ecki writes: > Currently we don't try to control backlight after detecting > (RHDRegRead(Output, RV620_LVTMA_BL_MOD_CNTL) & LVTMA_BL_MOD_EN) == 0 > > This assumption is quite wrong, because in some (many?) cases we can > just change this one bit and control backlight without problem. > Confirmed to work on M82==RV620.

This is possible but there is no guarantee. It could also be controlled by some OEM specific mechanism. In those cases we cannot control backlight, if at all it can be controlled over ACPI.

What do you mean by "OEM specific mechanism"? Just ACPI? Or something more? What will happen if we try to control (change) backlight on system where it is already controled by ACPI? Can this cause any unstability? Can ACPI control backlight using something else that registers we touch in radeonhd's code?

...

To not expose a backlight property if we cannot control it anyway I had decided to use this check.

I can control backlight this way anyway. So this is not right check. It cuts off control on system where it actually works fine. And we already know it's not only my specific case.

...

We could fall back to AtomBIOS controlled backlight in cases where we are not sure as this might be programmed correctly for the system in question - however to implement this would require some extra work as in the hard coded cases the needed data structures have not been set up.

Why AtomBIOS would be safer to use than using registers? What AtomBIOS command would you actually like to call? That whole AtomBIOSScratch code looks really messy for me. -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher

18:11

New subject: [PATCH] Somehow /force/ backlight control

2009/6/29 Rafał Miłecki :

...

W dniu 29 czerwca 2009 18:08 użytkownik Egbert Eich napisał:

...
Rafa? Mi?ecki writes: > Currently we don't try to control backlight after detecting > (RHDRegRead(Output, RV620_LVTMA_BL_MOD_CNTL) & LVTMA_BL_MOD_EN) == 0 > > This assumption is quite wrong, because in some (many?) cases we can > just change this one bit and control backlight without problem. > Confirmed to work on M82==RV620.

This is possible but there is no guarantee. It could also be controlled by some OEM specific mechanism. In those cases we cannot control backlight, if at all it can be controlled over ACPI.

What do you mean by "OEM specific mechanism"? Just ACPI? Or something more?

Some oems use the on-chip backlight control, others use some other method (gpio control, separate controller on the motherboard, etc.). The acpi method should work unless it requires access to the vga io space which IIRC radeonhd disables (at least it used to, not sure if it still does).

...

What will happen if we try to control (change) backlight on system where it is already controled by ACPI? Can this cause any unstability? Can ACPI control backlight using something else that registers we touch in radeonhd's code?

Yes. See above. The driver code in question only works for oem systems that use the on-chip backlight controller; not all oems do.

...

...
To not expose a backlight property if we cannot control it anyway I had decided to use this check.

I can control backlight this way anyway. So this is not right check. It cuts off control on system where it actually works fine. And we already know it's not only my specific case.

The problem is we don't know which systems uses which method.

...

...
We could fall back to AtomBIOS controlled backlight in cases where we are not sure as this might be programmed correctly for the system in question - however to implement this would require some extra work as in the hard coded cases the needed data structures have not been set up.

Why AtomBIOS would be safer to use than using registers? What AtomBIOS command would you actually like to call? That whole AtomBIOSScratch code looks really messy for me.

It may work for more cases depending on how the oem has chosen to wire up the backlight. IIRC, it's controlled by LCD1OutputControl on pre-DCE3 chips, and DIG2TransmitterControl on DCE3 and newer chips. As I recall, you set the requested level in one of the bios scratch regs and then execute the table with the action set to the appropriate LCD_BLOFF/BLON/BL_BRIGHTNESS_CONTROL for the table. See atombios.h. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Rafał Miłecki

30 Jun 30 Jun

08:40

New subject: [PATCH] Somehow /force/ backlight control

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. -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher

15:17

New subject: [PATCH] Somehow /force/ backlight control

2009/6/30 Rafał Miłecki :

...

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@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Rafał Miłecki

15:20

New subject: [PATCH] Somehow /force/ backlight control

W dniu 30 czerwca 2009 17:17 użytkownik Alex Deucher napisał:

...

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

What about machines which don't have ACPI method for controlling backlight? Like my annoying (at this point) VAIO FW11? I'm afraid it still not a solution :/ -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher

15:29

New subject: [PATCH] Somehow /force/ backlight control

2009/6/30 Rafał Miłecki :

...

W dniu 30 czerwca 2009 17:17 użytkownik Alex Deucher napisał:

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

What about machines which don't have ACPI method for controlling backlight? Like my annoying (at this point) VAIO FW11? I'm afraid it still not a solution :/

Sony may use an alternate acpi method name or tree location for their backlight control. You might want to look at the sony acpi platform driver. It may provide acpi backlight control if sony uses a non-standard method in your laptop. You could dump your acpi tables and poke around. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Rafał Miłecki

15:36

New subject: [PATCH] Somehow /force/ backlight control

W dniu 30 czerwca 2009 17:29 użytkownik Alex Deucher napisał:

...

2009/6/30 Rafał Miłecki :

...
W dniu 30 czerwca 2009 17:17 użytkownik Alex Deucher napisał:

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

What about machines which don't have ACPI method for controlling backlight? Like my annoying (at this point) VAIO FW11? I'm afraid it still not a solution :/

Sony may use an alternate acpi method name or tree location for their backlight control. You might want to look at the sony acpi platform driver. It may provide acpi backlight control if sony uses a non-standard method in your laptop. You could dump your acpi tables and poke around.

Already thought about this, without success: http://bugzilla.kernel.org/show_bug.cgi?id=11682 -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher

15:52

New subject: [PATCH] Somehow /force/ backlight control

2009/6/30 Rafał Miłecki :

...

W dniu 30 czerwca 2009 17:29 użytkownik Alex Deucher napisał:

...
2009/6/30 Rafał Miłecki :

...
W dniu 30 czerwca 2009 17:17 użytkownik Alex Deucher napisał:

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

What about machines which don't have ACPI method for controlling backlight? Like my annoying (at this point) VAIO FW11? I'm afraid it still not a solution :/

Sony may use an alternate acpi method name or tree location for their backlight control. You might want to look at the sony acpi platform driver. It may provide acpi backlight control if sony uses a non-standard method in your laptop. You could dump your acpi tables and poke around.

Already thought about this, without success: http://bugzilla.kernel.org/show_bug.cgi?id=11682

The reason the acpi backlight method doesn't work with radeonhd is that radeonhd disables vga io. The acpi method needs to access your cards registers to control the backlight. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

5483

Age (days ago)

5484

Last active (days ago)

List overview

Download

8 comments

3 participants

participants (3)

Alex Deucher
Egbert Eich
Rafał Miłecki