On Fri, 07 Aug 2009, Thomas Renninger wrote: > > 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. > 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. > > 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). > 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. > > 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. > 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. > 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 :-) -- "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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
