a backlight issue
Hi, Len
On some boxes there is neither generic ACPI backlight I/F nor
platform backlight I/F. That means that the backlight brightness can't be changed by using sys backlight I/F. But the backlight brightness can be changed by using the driver backlight I/F. For example: on the box based on intel-integrated graphics card the backlight brightness can also be changed by using the LBB register in pci device.
Can the graphics driver register the sys backlight I/F so that we
can change the backlight by using sys I/F?
If the graphics driver can also register the backlight I/F, it seems
that we can register three types of backlight I/F.
a. generic ACPI backlight I/F. This is registered by acpi video
driver.
b. platform backlight I/F. This is registered by the platform driver c. graphics backlight I/F. This can be registered by the graphics
driver.
As there exist three types of backlight I/F, how can we make the
coordination among the three backlight I/F? In fact only one backlight I/f is enough for user to change the brightness.
Rui provides a propose that use the backlight manager to choose the appropriate the backlight I/F.
backlight manager only exports one single I/F to users, like:
----|
|----brightness
|----actual_brightness
|----max_brightness
|----...
|----modeand it supports multiple modes, e.g.
1. generic ---ACPI
2. platform---platform drivers
3. legacy-----i915
The sysfs backlight manager always chooses the mode with highest priority (generic > platform > legacy), and call the respective callbacks when backlight is changed.
For example, the backlight manager switches to the "generic" mode from "legacy" mode automatically when ACPI video driver is loaded at runtime.
How about the above propose?
BTW: now in the video driver only one of acpi generic backlight I/F and platform backlight I/F is registered. That means that the acpi generic backlight I/F is preferred if it exists. Of course we can switch to the platform backlight I/F by adding the boot option of "acpi_backlight=vendor". In summary, the platform driver will check whether the acpi generic backlight is supported before registering the platform backlight I/F.
Thanks.
Hi,
Quoted 17 lines · yakui_zhao
On some boxes there is neither generic ACPI backlight I/F nor
platform backlight I/F. That means that the backlight brightness can't be changed by using sys backlight I/F. But the backlight brightness can be changed by using the driver backlight I/F. For example: on the box based on intel-integrated graphics card the backlight brightness can also be changed by using the LBB register in pci device.
Can the graphics driver register the sys backlight I/F so that we
can change the backlight by using sys I/F?If the graphics driver can also register the backlight I/F, it seems
that we can register three types of backlight I/F.
a. generic ACPI backlight I/F. This is registered by acpi video
driver.
b. platform backlight I/F. This is registered by the platform driver c. graphics backlight I/F. This can be registered by the graphics
driver.
Quoted 3 lines
As there exist three types of backlight I/F, how can we make the
coordination among the three backlight I/F? In fact only one backlight I/f is enough for user to change the brightness.
I think in the short term you're right and that there needs to be something acpi specific as a backlight arbitrator. This problem is quite specific to acpi. Its worth thinking about the wider picture too though.
Taking a machine with say, three graphics cards in it, what should happen? It should probably register one control for each screen with an adjustable backlight so if each card was dual head you'd get 6 controls.
The key problem is knowing which backlight interface corresponds to which driver+screen. If we had that information, exporting your three interfaces above might be less of an issue as userspace could tell they were for the same hardware. The kernel could pick the best interface internally too, if it can tell they're for the same screen.
I suspect at this point we've gone far beyond the environment the sysfs backlight interface was designed for and we'd be better off having the backlight control in parallel with the other screen data which probably runs through the DRM code.
Even then its not straightforward though as even just considering the i915 driver, can it always use the i915 registers for the backlight or does it sometimes have to make ACPI calls?
Cheers,
Richard
Signature · 2 lines
Richard Purdie Intel Open Source Technology Centre
Hi,
while looking out for latest work in this area:
ACPI vs vendor vs KMS kernel backlight concurrency
I saw this one and even late, it looks like the appropriate mail to answer as Yakui nicely describes the problem here...
Quoted 37 lines · On Thursday 25 June 2009 04:09:09 yakui_zhao wrote:
Hi, Len
On some boxes there is neither generic ACPI backlight I/F nor
platform backlight I/F. That means that the backlight brightness can't be changed by using sys backlight I/F. But the backlight brightness can be changed by using the driver backlight I/F. For example: on the box based on intel-integrated graphics card the backlight brightness can also be changed by using the LBB register in pci device.
Can the graphics driver register the sys backlight I/F so that we
can change the backlight by using sys I/F?If the graphics driver can also register the backlight I/F, it seems
that we can register three types of backlight I/F.
a. generic ACPI backlight I/F. This is registered by acpi video
driver.
b. platform backlight I/F. This is registered by the platform driver c. graphics backlight I/F. This can be registered by the graphics
driver.As there exist three types of backlight I/F, how can we make the
coordination among the three backlight I/F? In fact only one backlight I/f is enough for user to change the brightness.Rui provides a propose that use the backlight manager to choose the appropriate the backlight I/F.
backlight manager only exports one single I/F to users, like:----| |----brightness |----actual_brightness |----max_brightness |----... |----modeand it supports multiple modes, e.g.
1. generic ---ACPI
2. platform---platform drivers
3. legacy-----i915
Quoted 7 lines
The sysfs backlight manager always chooses the mode with highest priority (generic > platform > legacy), and call the respective callbacks when backlight is changed.
For example, the backlight manager switches to the "generic" mode from "legacy" mode automatically when ACPI video driver is loaded at runtime.How about the above propose?
If I understand this right every machine/BIOS does either provide:
- generic ACPI funcs
- vendor specific BIOS interface (served by oem-laptop.ko drivers)
It's just that for some vendors the latter is not implemented (due to lack of specifications), is that right?
In any case, what about this solution:
If in KMS drivers backlight switching method is implemented and can register for the generic backlight driver, it should always be disabled by default. Instead, KMS drivers should export a simple "backlight_enable" file somewhere in sysfs. If userspace doesn't find a sysfs backlight interface, it can do:
echo 1 >/sys/path_to_graphics_card/backlight_enable
and a backlight sysfs interface should pop up on success.
That would be similar to current xorg driver approach which do try to take over if no backlight sysfs interface found.
Thomas
BTW: Which mailinglist would be appropriate to reach KMS developers?
Quoted 18 lines
BTW: now in the video driver only one of acpi generic backlight I/F and platform backlight I/F is registered. That means that the acpi generic backlight I/F is preferred if it exists. Of course we can switch to the platform backlight I/F by adding the boot option of "acpi_backlight=vendor". In summary, the platform driver will check whether the acpi generic backlight is supported before registering the platform backlight I/F.
Thanks.
--
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
Quoted 7 lines · Thomas Renninger
If in KMS drivers backlight switching method is implemented and can register for the generic backlight driver, it should always be disabled by default. Instead, KMS drivers should export a simple "
backlight_enable" file somewhere in sysfs. If userspace doesn't find a sysfs backlight interface, it can do:
echo 1 >/sys/path_to_graphics_card/backlight_enable
and a backlight sysfs interface should pop up on success.
IMO, we already have an in-kernel selector of the backlight control method for mutually-exclusive backlight control strategies. We should use that, and if it is complete/good enough to add the KMS scenario, improve it.
Signature · 4 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Quoted 10 lines · On Thursday 06 August 2009 14:55:52 Henrique de Moraes Holschuh wrote:
Quoted 8 lines · Thomas Renninger
If in KMS drivers backlight switching method is implemented and can register for the generic backlight driver, it should always be
disabled by default. Instead, KMS drivers should export a simple "backlight_enable" file somewhere in sysfs. If userspace doesn't find a sysfs backlight interface, it can do:
echo 1 >/sys/path_to_graphics_card/backlight_enable
and a backlight sysfs interface should pop up on success.
Quoted 2 lines
IMO, we already have an in-kernel selector of the backlight control method for mutually-exclusive backlight control strategies.
You mean the ACPI vs native driver detection?
Quoted 2 lines
We should use that, and if it is complete/good enough to add the KMS scenario, improve it.
You mean if it is *not* complete/good enough?
KMS popping in as a third kernel backlight provider makes things really complicated for the kernel to choose the right thing. Getting this prio:
1. generic ---ACPI
2. platform---platform drivers
3. legacy-----i915
solved in kernel automatically you need something like Rui/Yakui suggested:
- Let KMS register first as I expect it will always initialize first
- Let ACPI or platform driver unregister KMS backlight interface and take over
You never know when userspace plans to load the native drivers. This complexity for a normally not needed fallback (ACPI or native drivers should be available) is complicated and error-prone. This complexity should really be put to userspace where it's easy (three lines in bash) to solve, like I suggested above.
Maybe someone has another, easier idea to perfectly solve this automatically in kernel, I do not see it.
Thomas
Quoted 11 lines · Thomas Renninger
Quoted 10 lines · On Thursday 06 August 2009 14:55:52 Henrique de Moraes Holschuh wrote:
Quoted 8 lines · Thomas Renninger
If in KMS drivers backlight switching method is implemented and can register for the generic backlight driver, it should always be
disabled by default. Instead, KMS drivers should export a simple "backlight_enable" file somewhere in sysfs. If userspace doesn't find a sysfs backlight interface, it can do:
echo 1 >/sys/path_to_graphics_card/backlight_enable
and a backlight sysfs interface should pop up on success.
Quoted 3 lines
Quoted 2 lines
IMO, we already have an in-kernel selector of the backlight control method for mutually-exclusive backlight control strategies.
You mean the ACPI vs native driver detection?
Yes.
Quoted 3 lines
Quoted 2 lines
We should use that, and if it is complete/good enough to add the KMS scenario, improve it.
You mean if it is *not* complete/good enough?
Yes, sorry about that.
Quoted 4 lines
KMS popping in as a third kernel backlight provider makes things really complicated for the kernel to choose the right thing. Getting this prio:
1. generic ---ACPI
Quoted 8 lines
2. platform---platform drivers
3. legacy-----i915
solved in kernel automatically you need something like Rui/Yakui suggested:
- Let KMS register first as I expect it will always initialize first
- Let ACPI or platform driver unregister KMS backlight interface and take over
You never know when userspace plans to load the native drivers.
Or unload them, which should be fully supported...
Quoted 2 lines
This complexity for a normally not needed fallback (ACPI or native drivers should be available) is complicated and error-prone.
More error-prone than OpRegion and the SMM mess from hell on most laptops?
Quoted 5 lines
This complexity should really be put to userspace where it's easy (three lines in bash) to solve, like I suggested above.
Maybe someone has another, easier idea to perfectly solve this automatically in kernel, I do not see it.
I do, but I don't know if it is a better solution. In its "purest" form it would be: Teach the backlight core to have backlight domains and add a backlight domain controler there.
You get KMS, platform drivers taking care of the main LVDS screen, and ACPI on a single domain, let the kernel select ACPI by default or a different one by command line, and let userspace change it through sysfs.
Drivers need some change to actually just register their backlight hooks (plus hooks for "activate driver" and "deactivate driver", which are new) with the backlight domain controller instead of a full backlight device/class. Other backlight drivers just register their own device using the existing API.
Now, is that a better solution? I don't know. But it is more user-friendly than what we have now, and more powerful. It is also more complex.
Signature · 4 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Quoted 58 lines · On Thursday 06 August 2009 21:50:32 Henrique de Moraes Holschuh wrote:
Quoted 11 lines · Thomas Renninger
Quoted 10 lines · On Thursday 06 August 2009 14:55:52 Henrique de Moraes Holschuh wrote:
Quoted 8 lines · Thomas Renninger
If in KMS drivers backlight switching method is implemented and can register for the generic backlight driver, it should always be
disabled by default. Instead, KMS drivers should export a simple "backlight_enable" file somewhere in sysfs. If userspace doesn't find a sysfs backlight interface, it can do:
echo 1 >/sys/path_to_graphics_card/backlight_enable
and a backlight sysfs interface should pop up on success.Quoted 3 lines
Quoted 2 lines
IMO, we already have an in-kernel selector of the backlight control method for mutually-exclusive backlight control strategies.
You mean the ACPI vs native driver detection?
Yes.
Quoted 3 lines
Quoted 2 lines
We should use that, and if it is complete/good enough to add the KMS scenario, improve it.
You mean if it is *not* complete/good enough?
Yes, sorry about that.
Quoted 4 lines
KMS popping in as a third kernel backlight provider makes things really complicated for the kernel to choose the right thing. Getting this prio:
1. generic ---ACPIQuoted 8 lines
2. platform---platform drivers
3. legacy-----i915
solved in kernel automatically you need something like Rui/Yakui suggested:
- Let KMS register first as I expect it will always initialize first
- Let ACPI or platform driver unregister KMS backlight interface and take over
You never know when userspace plans to load the native drivers.Or unload them, which should be fully supported...
Quoted 2 lines
This complexity for a normally not needed fallback (ACPI or native drivers should be available) is complicated and error-prone.
More error-prone than OpRegion and the SMM mess from hell on most laptops?
Quoted 5 lines
This complexity should really be put to userspace where it's easy (three lines in bash) to solve, like I suggested above.
Maybe someone has another, easier idea to perfectly solve this automatically in kernel, I do not see it.
I do, but I don't know if it is a better solution. In its "purest" form it would be: Teach the backlight core to have backlight domains and add a backlight domain controler there.
You get KMS, platform drivers taking care of the main LVDS screen, and ACPI on a single domain, let the kernel select ACPI by default or a different one by command line, and let userspace change it through sysfs.
Quoted 7 lines
Drivers need some change to actually just register their backlight hooks (plus hooks for "activate driver" and "deactivate driver", which are new) with the backlight domain controller instead of a full backlight device/class. Other backlight drivers just register their own device using the existing API.
Now, is that a better solution? I don't know.
I don't think so. It sounds like quite some code/complexity that needs to be added for no functional enhancement.
This is all about solving the complexity in kernel or in userspace. As it is *much* easier in userspace, I'd go that way.
Quoted 1 line
But it is more user-friendly than what we have now, and more powerful.
Why is it more powerful?
It's about solving the problem in kernel or in userspace, while userspace might have additional info for choosing the right thing.
Quoted 1 line
It is also more complex.
Which is a very strong argument.
Thomas
BTW: How would several graphics cards/monitors and switching between them be handled currently or in future?
I once had such a machine and IIRC you ended up in double steps using generic ACPI backlight funcs on both graphics cards. When I saw the two active ACPI graphics devices I was happy that this was the only related defect and silently ignored it :)
Quoted 14 lines · Thomas Renninger
Quoted 14 lines
I do, but I don't know if it is a better solution. In its "purest" form it would be: Teach the backlight core to have backlight domains and add a backlight domain controler there.
You get KMS, platform drivers taking care of the main LVDS screen, and ACPI on a single domain, let the kernel select ACPI by default or a different one by command line, and let userspace change it through sysfs.
Drivers need some change to actually just register their backlight hooks (plus hooks for "activate driver" and "deactivate driver", which are new) with the backlight domain controller instead of a full backlight device/class. Other backlight drivers just register their own device using the existing API.
Quoted 5 lines
Quoted 1 line
Now, is that a better solution? I don't know.
I don't think so. It sounds like quite some code/complexity that needs to be added for no functional enhancement.
This is all about solving the complexity in kernel or in userspace. As it is *much* easier in userspace, I'd go that way.
I might even agree with you, but I object that any interface that publishes broken controls to userspace is good. We should only expose stuff that works, if KMS is busted in a given platform, no KMS controls should be exposed, etc. Publishing two controls that "work" but fight each other is worse.
Besides, we *have* the notion of a main screen on almost every platform, and exposing the main screen backlight control in a single way (and allowing the user to select the backlight control strategy at runtime, after we did our best to select the proper one by default) is much more user-fiendly and neat.
What we have currently just barely cuts it, and wouldn't handle secondary displays of any sort.
Quoted 2 lines
Quoted 1 line
But it is more user-friendly than what we have now, and more powerful.
Why is it more powerful?
See above. One can override the control strategy at runtime to select any backlight driver that could work (this assumes backlight drivers refuse to install when the support they need isn't there, which is a safe assumption as that's exactly what we try to do already).
Quoted 2 lines
It's about solving the problem in kernel or in userspace, while userspace might have additional info for choosing the right thing.
It can still choose. But now almost every userspace app has a single control point. Just like we do in the API used for kernel drivers, we should aim for userspace ABIs that are easy to use right.
Quoted 2 lines
Quoted 1 line
It is also more complex.
Which is a very strong argument.
Not that strong, the added complexity is NOT too high, as backlight _already_ operates based on context that is passed around as a pointer, and on hooks that are inside this context structure. Also, the propler layering already exists.
I'd say it is a matter of a few hundred lines of code in the backlight class, and the change of one function call on the backend drivers, to register the backlight class on the proper domain.
Quoted 2 lines
BTW: How would several graphics cards/monitors and switching between them be handled currently or in future?
The above "backlight domain controller" could take care of it with very small changes to the design.
Quoted 4 lines
I once had such a machine and IIRC you ended up in double steps using generic ACPI backlight funcs on both graphics cards. When I saw the two active ACPI graphics devices I was happy that this was the only related defect and silently ignored it :)
I do expect we will have some headaches on the firmware side of things, yes :-)
Signature · 4 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh