Backlight maintainer added to CC. On Sat, 28 Nov 2009, Rafa?? Mi??ecki wrote: > W dniu 28 listopada 2009 01:30 u??ytkownik Rafa?? Mi??ecki > <zajec5@xxxxxxxxx> napisa??: > > Currently we keep all registered controllers in /sys/class/backlgiht/ > > without any grouping per display or per anything. We can not use > > grouping per GPU (as somewhere proposed) because one GPU can control > > (for example) two PANELS and TV - 3 displays needing backlight > > management. The most obvious and stable solution seems to be grouping > > per display. > > Just in case I was not clear enough. We should make ACPI, platform and > GPU drivers register same panel backlight control under same name like > "panel-0". Backlight class device would create > /sys/class/backlight/panel-0 only. When touching files in this > backlight/panel-0/, blacklight class would call functions from the > most proper (ACPI > platform > GPU) driver. > I once suggested some sort of multiplexer backlight device that would do exactly that. Various drivers (platform, ACPI, display) would register backends and specify some sort of dynamic preference so that the kernel would have a good bet on the default one, and userspace could switch the active backend later if it wanted. In this case, we'd have to specify properties or some other way to group the backends properly and to easily let userspace find the backlight device it needs to drive a specific device. > I thought if we could use card number for anything. I recalled that > notebooks with hybrid gpu, where system should switch between weaker > and more powerful GPU watching load. In case of that notebooks PANEL > can be controlled by both: card0 and card1. That would require backends to be able to runtime register and unregister themselves with the main backlight device, and that they hook somehow on the hotplug stuff, to know when to bind/unbind along with the GPU. > So finally I think we should just register panel0 by default > everywhere. And in future we could add some quirks in drivers (ACPI, > platform, GPU) that would register panel1, panel2... for such devices. If you're going to design something, do it properly from day one. Address all the main issues: multiple backends for each device, auto-selection of the default backend based on data reported by the backend drivers (e.g. a platform driver usually knows very well if it should be preferred over ACPI and GPU or not...), *and* multiple devices with hotplug. These are not, after all, overengineering for the future. It is a problem we have _now_ with real world devices that are shipping. There are other ways to solve this issue, of course, and they're easier: publish MORE information on sysfs to properly bind backlight devices to the real device they control, as well as more data to help userspace decide which one it should use. It is a cop-out, as we are only solving half the problem space in-kernel. But it works, and it is not a hack, so it is also a viable solution. I prefer the full kernel solution where we export just one backlight interface, but when I propesed it, the others made it clear they'd prefer the less complex "userspace chooses which backlight backend to drive" currently employed. Meanwhile, I'd like a LOT to know how I could parent the backlight device I export in a platform driver to the correct PCI or ACPI device for the main GPU... -- "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
