>>>>> "Hans" == Hans Verkuil <hverkuil@xxxxxxxxx> writes: Hi, Hans> But I feel I am missing something: who is supposed to use these LEDs? Hans> Turning LEDs in e.g. webcams on or off is a job for the driver, never for Hans> a userspace application. Agreed - By default, the driver should just turn on the LED when the device is active and off again when it is not. Hans> For that matter, if the driver handles the LEDs, Hans> can we still expose the API to userspace? Wouldn't those two interfere Hans> with one another? I know nothing about the LED interface in sysfs, but I Hans> can imagine that will be a problem. Yes, you expose the LED using the LED class, and add a LED trigger per video device (named something like "videoX-active"). Furthermore you set the default trigger for that LED to be videoX-active. So the logic of how to turn on/off the LED is seperated from the policy about WHEN it should be turned on/off. >> Sysfs entry ownership, unix permissions, and ACL permissions consistency >> with /dev/videoN will be the immediate usability problem for end users in >> any case. Hans> Again, why would end users or application need or want to manipulate such Hans> LEDs in any case? In most cases they don't - Not using the LED sysfs or v4l. But if they do, then they CAN. -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
