On Tue, Apr 8, 2025 at 12:27 AM Daniel Thompson <dan...@riscstar.com> wrote: > On Mon, Apr 07, 2025 at 05:51:17PM +0800, Pengyu Luo wrote: > > Kinetic ktz8866, found in many android devices, nowadays, some oem use > > dual ktz8866 to support a larger panel and higher brightness, original > > driver would only handle half backlight region on these devices, > > registering it twice is unreasonable, so adding the slave handler to > > support it. > > Is there anything unique about KTZ8866 that allows it to be used like > this? I think it would be better to add support for secondary backlight > controllers into the backlight framework, rather than having to > implement driver specific hacks for every backlight controller that > appears in a primary/secondary configuration. >
According to my understanding, if I add the new api to backlight framework, with a minimal modification, then I either do A or do B(I doubt it is my fixed mindset) A: Tied two devices, registering the primary and the secondary device during one probe, to do that, I access another KTZ8866 when probing. Those hack is still here, that doesn't seem to help. B: Uncoupled, probing separately, the later one is registered as the secondary one. Brightness control is a little uncoupled, there are two sysfs, I doubt if userspace programs will write brightness to two devices. Then we need synchronization, write primary => write primary and write secondary, viceversa. > Also, the kernel seeks to avoid adding new instances of master/slave > terminology. See the coding style doc for suggested alternatives: > https://www.kernel.org/doc/html/latest/process/coding-style.html#naming > Agree. Best wishes, Pengyu
