:The backlight issue when KMS is used

RFC Zhang Rui 5 participants 9 messages Apr 7, 2009 – Apr 9, 2009 9 messages not in the archive ACPI

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 20090403092408.66809996@hobbes

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 1239092434.7661.87.camel@rzhang-dt

A message that is not in the archive (sent off-list or not yet received): [email protected]

Zhang Rui

author

2009-04-07 08:48 UTC #8 lore raw

CC Thomas, Len and linux-acpi mail list.

Quoted 16 lines · Matthew Garrett

Quoted 9 lines · Zhang Rui
All subsystems can register a set of callbacks for backlight control in its own way, e.g. ACPI, platform driver, i915.
And the backlight manager only exports one single I/F to users, like:
----|
    |----brightness
    |----actual_brightness
    |----max_brightness
    |----...
    |----mode
Quoted 4 lines
and it supports multiple modes, e.g.
1. generic ---ACPI
2. platform---platform drivers
3. legacy-----i915

Quoted 2 lines

This seems to be a lot of complexity for an uncommon case. Is there any real need to modify the mode at runtime?

if this is implemented, the video_detect.c can be removed because we don't need to detect the ACPI video extension when loading platform drivers.
every driver that has its own ways to control the backlight can register a set of callbacks and then it's the backlight manager's responsibility to choose which one to use.

Quoted 3 lines

What happens if the platform
driver gets loaded before i915?

the backlight manager always choose the one with the highest priority if multiple callbacks are registered. i.e
if (ACPI control methods are available)
changes to the "generic" mode
else if (platform specific callbacks are available)
changes to the "platform" mode
else if (i915 callbacks are available)
changes to the "legacy" mode

the backlight manager always run this logic when a new set of callbacks is registered/unregistered.

thanks,
rui

Jesse Barnes

2009-04-07 23:27 UTC #9 lore raw

Quoted 41 lines · On Tue, 07 Apr 2009 16:48:22 +0800 Zhang Rui <[email protected]> wrote:

CC Thomas, Len and linux-acpi mail list.
Quoted 16 lines · Matthew Garrett
Quoted 9 lines · Zhang Rui
All subsystems can register a set of callbacks for backlight control in its own way, e.g. ACPI, platform driver, i915. And the backlight manager only exports one single I/F to users,
like: ----|
    |----brightness
    |----actual_brightness
    |----max_brightness
    |----...
    |----mode
Quoted 4 lines
and it supports multiple modes, e.g.
1. generic ---ACPI
2. platform---platform drivers
3. legacy-----i915
Quoted 2 lines
This seems to be a lot of complexity for an uncommon case. Is there any real need to modify the mode at runtime?
if this is implemented, the video_detect.c can be removed because we don't need to detect the ACPI video extension when loading platform drivers.
every driver that has its own ways to control the backlight can register a set of callbacks and then it's the backlight manager's responsibility to choose which one to use.
Quoted 3 lines
What happens if the platform
driver gets loaded before i915?
the backlight manager always choose the one with the highest priority if multiple callbacks are registered. i.e
if (ACPI control methods are available)
changes to the "generic" mode
else if (platform specific callbacks are available)
changes to the "platform" mode
else if (i915 callbacks are available)
changes to the "legacy" mode

Quoted 2 lines

the backlight manager always run this logic when a new set of callbacks is registered/unregistered.

The other option of course (as discussed this morning on IRC w/Dr_Jackob) is to avoid using the sysfs backlight API in the KMS case (KMS clients would be expected to go through output properties instead). This has the disadvantage of essentially deprecating a currently used interface, but OTOH making for a more consistent interface across new output types with brightness control (DDC has bits for this, as does displayport I think).

But we'd definitely want to preserve the current ACPI interaction, so we'd have to make the i915 and other DRM drivers clients of the ACPI or platform backlight drivers (at least internally to the kernel) where available.

This might be a bit simpler than the de-registration stuff we talked about, and would intuitively extend to other output types that add backlight support in the future.

Any thoughts about that?

Signature · 12 lines

Jesse Barnes, Intel Open Source Technology Center

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel

yakui_zhao

2009-04-08 00:58 UTC #10 lore raw

In reply to Zhang Rui

Quoted 41 lines · Rui

CC Thomas, Len and linux-acpi mail list.
Quoted 16 lines · Matthew Garrett
Quoted 9 lines · Zhang Rui
All subsystems can register a set of callbacks for backlight control in its own way, e.g. ACPI, platform driver, i915.
And the backlight manager only exports one single I/F to users, like:
----|
    |----brightness
    |----actual_brightness
    |----max_brightness
    |----...
    |----mode
Quoted 4 lines
and it supports multiple modes, e.g.
1. generic ---ACPI
2. platform---platform drivers
3. legacy-----i915
Quoted 2 lines
This seems to be a lot of complexity for an uncommon case. Is there any real need to modify the mode at runtime?
if this is implemented, the video_detect.c can be removed because we don't need to detect the ACPI video extension when loading platform drivers.
every driver that has its own ways to control the backlight can register a set of callbacks and then it's the backlight manager's responsibility to choose which one to use.
Quoted 3 lines
What happens if the platform
driver gets loaded before i915?
the backlight manager always choose the one with the highest priority if multiple callbacks are registered. i.e
if (ACPI control methods are available)
changes to the "generic" mode
else if (platform specific callbacks are available)
changes to the "platform" mode
else if (i915 callbacks are available)
changes to the "legacy" mode

Quoted 2 lines

the backlight manager always run this logic when a new set of callbacks is registered/unregistered.

Is this manager realized in kernel space or user space?

Quoted 3 lines

thanks,
rui

Thomas Renninger

2009-04-08 07:54 UTC #11 lore raw

In reply to Zhang Rui

Quoted 21 lines · On Tuesday 07 April 2009 10:48:22 Zhang Rui wrote:

CC Thomas, Len and linux-acpi mail list.
Quoted 18 lines · Matthew Garrett
Quoted 9 lines · Zhang Rui
All subsystems can register a set of callbacks for backlight control in its own way, e.g. ACPI, platform driver, i915.
And the backlight manager only exports one single I/F to users, like:
----|
    |----brightness
    |----actual_brightness
    |----max_brightness
    |----...
    |----mode
Quoted 4 lines
and it supports multiple modes, e.g.
1. generic ---ACPI
2. platform---platform drivers
3. legacy-----i915
This seems to be a lot of complexity for an uncommon case. Is there any real need to modify the mode at runtime?

Whatabout several graphics cards, vendors are already selling. If you switch the graphics cards you also might have to pick up another backlight back-end?

Quoted 3 lines

if this is implemented, the video_detect.c can be removed because we don't need to detect the ACPI video extension when loading platform drivers.

Hmm, above pretty much looks like what video_detect.c does + i915 detection. One problem is that you have to detect things before drivers are loaded and possibly register the wrong interface, so this needs to be implemented in code that is always compiled in.
Are there more details where and how this should get implemented? Or can someone provide a pointer to the beginning of the thread? The graphics driver was the missing part when choosing who is going to switch things. Now that it moves into the kernel, synchronization between all above drivers is probably a good idea.

Whatabout display output switching?
The problem is similar, you have:
- vendor specific (e.g. in thinkpad-laptop)
- ACPI
- graphics driver
Here the first two never really worked (at least for a large range of systems) AFAIK. AFAIK 3D graphics drivers disable IO regions so that ACPI or others cannot change them anymore and take over. How is this supposed to work with (and without) KMS?

Thomas

Quoted 22 lines

every driver that has its own ways to control the backlight can register a set of callbacks and then it's the backlight manager's responsibility to choose which one to use.
Quoted 3 lines
What happens if the platform
driver gets loaded before i915?
the backlight manager always choose the one with the highest priority if multiple callbacks are registered. i.e
if (ACPI control methods are available)
changes to the "generic" mode
else if (platform specific callbacks are available)
changes to the "platform" mode
else if (i915 callbacks are available)
changes to the "legacy" mode
the backlight manager always run this logic when a new set of callbacks is registered/unregistered.
thanks,
rui

A message that is not in the archive (sent off-list or not yet received): [email protected]

yakui_zhao

2009-04-08 00:55 UTC #13 lore raw

Quoted 15 lines · Matthew Garrett

Quoted 6 lines · yakui_zhao
Quoted 1 line · Matthew Garrett
No, since in UMS mode the X server handles the backlight registers.
If so, there is no change about the backlight flowchart in UMS mode.
And only when the KMS mode is used, a new backlight I/F is registered. Right?
Right.
Quoted 5 lines
Quoted 5 lines
The acpi case is uninteresting - acpi_video_backlight_support() doesn't require the acpi video driver. The platform driver case is more interesting, but the easiest solution is probably to add a notifier chain for backlight device add and have i915 unregister when a platform device registers.

Quoted 7 lines

Quoted 5 lines
Yes. We will have to create the communication channel between backlight device and i915 driver. And when a backlight I/F is registered, we will have to check whether the backlight I/F in 915 should be unregistered. Right?
Does this make the problem complex?
Not really. It's not a lot of code.

When a new backlight I/F is registered, it should unregister the backlight I/F registered in 915 driver if it exists. And before i915 driver registers a backlight I/F, it will have to check whether the backlight I/F is already registered by other code. If it exists, it will give up.
And this code seems hack.

If so, we will have to do so even for the boxes based on non-intel platforms.

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
I'm not sure what you mean by arbiter order?
What I said is which backlight I/F should be selected if there exist multiple backlight I/F?
The platform-specific one.

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Thomas Renninger

2009-04-08 10:17 UTC #14 lore raw

Hi,

We have these interfaces:
- vendor specific implementation
(mostly in drivers/platform/x86/vendor-laptop.c)
- ACPI generic backlight only
- Opregion (this is the KMS/i915 interface you are talking about or is there another abstraction?)
- Possibly other graphics card specific coming up with KMS?
- X-server is doing it (UMS)

Matthew and Jesse are looking for following approach:
Let all drivers try to register for the generic backlight interface. As we do not know which driver will get loaded first, you want to detect whether another driver already registered the backlight interface and implement a priority to eventually let the newly loaded driver unregister the other driver's backlight device, notify this driver via a notifier chain and then register the own backlight interface (is that correct?).

Priority could look like:
1) vendor specific drivers
2) ACPI generic drivers
3) Graphics card's specific kernel drivers (IGD/Opregion and possibly others)
3 has highest prio.

If I got that right, I do not like:
- the complexity that has to be added to the generic backlight interface and each backlight driver.
- The fact that several HW access mechanisms might be used. That all are working is rather unlikely. Once e.g. Windows is only using IGD, OEMs might still have a not working vendor specific solution remaining in their BIOSes. If the vendor specific solution is registered first the machine might in worst case freeze, before the i915 driver could have taken over.

Whatabout a similar approach like video_detect which checks for ACPI generic functions and fills a global variable which mechanism to go for before module load time.

If the i915 backlight switching is the IGD implementation, then video_detect.c is nearly already sufficient. All that has to be added is whether generic ACPI backlight functions support IGD and acpi_video_backlight_support() must not only return true/false, but e.g.:
1 (no acpi things, go for vendor specific)
2 (generic ACPI functions, but no IGD, go for video.ko) 3 (generic ACPI functions and IGD, video.ko will not register for
backlight)

The main problem with that approach is (for IGD it might not be that hard, but for other upcoming graphics cards?), that if the card has to be set up first in a complex way (e.g. atombios things for Radeon must be parsed before) you have to statically compile in all necessary things to check whether the later loaded graphics cards driver can serve backlight functionality or not.
If upcoming other graphics cards kernel drivers all can do backlight switching on all cards, it could simply be checked for:
"vendor pci id of the graphics card" + "KMS set in .config"

Advantage:
- It does not have above mentioned disadvantages
- It's easy to add boot params or a blacklist to fallback to another backlight solution

Disadvantage:
- You have the backlight functionality detection code compiled into the kernel
- The code could get complex if graphics cards have to be set up or similar to check whether a KMS graphics driver will be able to do backlight switching

Thomas

Richard Purdie

2009-04-08 10:50 UTC #15 lore raw

Quoted 16 lines · Thomas Renninger

Matthew and Jesse are looking for following approach:
Let all drivers try to register for the generic backlight interface. As we do not know which driver will get loaded first, you want to detect whether another driver already registered the backlight interface and implement a priority to eventually let the newly loaded driver unregister the other driver's backlight device, notify this driver via a notifier chain and then register the own backlight interface (is that correct?).
Priority could look like:
1) vendor specific drivers
2) ACPI generic drivers
3) Graphics card's specific kernel drivers (IGD/Opregion and possibly others)
3 has highest prio.

Quoted 3 lines

If I got that right, I do not like:
- the complexity that has to be added to the generic backlight interface and each backlight driver.

I'm not arguing for or against any approach here but if we need to have this priority handoff system, I'd like to see it as a wrapper around the backlight class and the class itself is unlikely to need changes. The wrapper would register one backlight device with the generic class and then redirect the function calls as needed.

Cheers,

Richard

yakui_zhao

2009-04-09 01:11 UTC #16 lore raw

In reply to Thomas Renninger

Quoted 8 lines · Thomas Renninger

Hi,
We have these interfaces:
- vendor specific implementation
(mostly in drivers/platform/x86/vendor-laptop.c)
- ACPI generic backlight only
- Opregion (this is the KMS/i915 interface you are talking about or is there another abstraction?)

IMO it is unnecessary to consider the Opregion as the interface. In fact it is only for the communication between the ACPI and graphics driver. We can send the request by using ACPI generic backlight and then the brightness is changed in the graphics driver.

Quoted 2 lines

- Possibly other graphics card specific coming up with KMS?
- X-server is doing it (UMS)

Yes. For example: three other control methods are provided in UMS for intel driver. Native/ Legacy/ Combo mode.
And the control methods are hook up by Xrandr tool.

Quoted 41 lines

Matthew and Jesse are looking for following approach:
Let all drivers try to register for the generic backlight interface. As we do not know which driver will get loaded first, you want to detect whether another driver already registered the backlight interface and implement a priority to eventually let the newly loaded driver unregister the other driver's backlight device, notify this driver via a notifier chain and then register the own backlight interface (is that correct?).
Priority could look like:
1) vendor specific drivers
2) ACPI generic drivers
3) Graphics card's specific kernel drivers (IGD/Opregion and possibly others)
3 has highest prio.
If I got that right, I do not like:
- the complexity that has to be added to the generic backlight interface and each backlight driver.
- The fact that several HW access mechanisms might be used. That all are working is rather unlikely. Once e.g. Windows is only using IGD, OEMs might still have a not working vendor specific solution remaining in their BIOSes. If the vendor specific solution is registered first the machine might in worst case freeze, before the i915 driver could have taken over.
Whatabout a similar approach like video_detect which checks for ACPI generic functions and fills a global variable which mechanism to go for before module load time.
If the i915 backlight switching is the IGD implementation, then video_detect.c is nearly already sufficient. All that has to be added is whether generic ACPI backlight functions support IGD and acpi_video_backlight_support() must not only return true/false, but e.g.:
1 (no acpi things, go for vendor specific)
2 (generic ACPI functions, but no IGD, go for video.ko) 3 (generic ACPI functions and IGD, video.ko will not register for
backlight)

Quoted 9 lines

The main problem with that approach is (for IGD it might not be that hard, but for other upcoming graphics cards?), that if the card has to be set up first in a complex way (e.g. atombios things for Radeon must be parsed before) you have to statically compile in all necessary things to check whether the later loaded graphics cards driver can serve backlight functionality or not.
If upcoming other graphics cards kernel drivers all can do backlight switching on all cards, it could simply be checked for:
"vendor pci id of the graphics card" + "KMS set in .config"

What you said is also OK.
But I don't know whether this will make the problem complex. This issue I raised is related with that no backlight can be controlled by xrandr tool after using KMS.
For example: >http://bugs.freedesktop.org/show_bug.cgi?id=20963

On this box neither generic ACPI backlight I/F nor platform
backlight I/F exists. In UMS mode the backlight can be controlled by xrandr(the specific control method is used). But in KMS mode the specific control method is realized in kernel space and this is not exposed to user space. In such case the backlight can't be controlled.
And we expect that the backlight still can be controlled by xrandr
tool in KMS mode.

Another issue is the inconsistency between the ACPI backlight I/F and specific control method.
For example: there exists the generic ACPI backlight I/F and this
depends on intel opregion. If the legacy control method is selected, then ACPI backlight I/F can't report the correct brightness after the brightness is changed by xrandr tool.
So we expect to avoid the inconsistency in KMS mode.

Quoted 14 lines

Advantage:
- It does not have above mentioned disadvantages
- It's easy to add boot params or a blacklist to fallback to another backlight solution
Disadvantage:
- You have the backlight functionality detection code compiled into the kernel
- The code could get complex if graphics cards have to be set up or similar to check whether a KMS graphics driver will be able to do backlight switching
Thomas

Thomas Renninger

2009-04-09 07:41 UTC #17 lore raw

Quoted 15 lines · yakui_zhao

Quoted 8 lines · Thomas Renninger
Hi,
We have these interfaces:
- vendor specific implementation
(mostly in drivers/platform/x86/vendor-laptop.c)
- ACPI generic backlight only
- Opregion (this is the KMS/i915 interface you are talking about or is there another abstraction?)
IMO it is unnecessary to consider the Opregion as the interface. In fact it is only for the communication between the ACPI and graphics driver. We can send the request by using ACPI generic backlight and then the brightness is changed in the graphics driver.

Quoted 5 lines

What you said is also OK.
But I don't know whether this will make the problem complex. This issue I raised is related with that no backlight can be controlled by xrandr tool after using KMS.
    For example: >http://bugs.freedesktop.org/show_bug.cgi?id=20963

Why should this get a i915 and not a native samsung-laptop driver? Can someone come up with some example code how the backlight switching implementation for this one would look like.
This is needed anyway and then it is much easier to think about how to make sure backlight drivers do not get double registered.

Thomas