On Mon, 4 Sep 2023, Thomas Weißschuh wrote:
+Cc Hans who ins involved with the backlight subsystem Hi Julius, today I stumbled upon a mail from Hans [0], which explains that the backlight subsystem is not actually a good fit (yet?) for external displays. It seems a new API is in the works that would better fit, but I'm not sure about the state of this API. Maybe Hans can clarify. This also ties back to my review question how userspace can figure out to which display a backlight devices applies. So far it can not. [0] https://lore.kernel.org/lkml/7f2d88de-60c5-e2ff-9b22-acba35cfdfb6@xxxxxxxxxx/
Hi Thomas, thanks for the hint. I will make sure to give this a proper read and see, if it fits my use case better then the current backlight subsystem. Especially since I wasnt able to properly address your other review comments for now. You are right that the name should align better with the kernel module and also, that it is possible for multiple displays to be attached. In its current state, this would mean that you could only control the backlight for the first HID device (enough for me :-). The systemd-backlight@.service uses not only the file name, but also the full bus path for storing/restoring backlights. I did not yet get around to see how the desktops handle brightness control, but since the systemd-backlight@.service already uses the name, its important to stay the same over multiple boots. I would be able to get a handle on the underlying USB device and use the serial to uniquely (and persistently) name the backlight. But it does feel hacky doing it this way. Anyways, this is where am at. Thanks again for the support and I will try my best to come up with something better. Julius
