Hi Bryan, On Thursday 10 October 2013 17:02:18 Bryan Wu wrote: > On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote: > > On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote: > >> On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote: > >> > On Mon, Sep 23, 2013 at 10:27:06PM +0200, Sylwester Nawrocki wrote: > >> >> On 09/23/2013 06:37 PM, Oliver Schinagl wrote: > >> >>> On 09/23/13 16:45, Sylwester Nawrocki wrote: > >> >>>> Hi, > >> >>>> > >> >>>> I would like to have a short discussion on LED flash devices support > >> >>>> in the kernel. Currently there are two APIs: the V4L2 and LED class > >> >>>> API exposed by the kernel, which I believe is not good from user > >> >>>> space POV. Generic applications will need to implement both APIs. I > >> >>>> think we should decide whether to extend the led class API to add > >> >>>> support for more advanced LED controllers there or continue to use > >> >>>> the both APIs with overlapping functionality. There has been some > >> >>>> discussion about this on the ML, but without any consensus reached > >> >>>> [1]. > >> >>> > >> >>> What about the linux-pwm framework and its support for the backlight > >> >>> via dts? > >> >>> > >> >>> Or am I talking way to uninformed here. Copying backlight to > >> >>> flashlight with some minor modification sounds sensible in a way... > >> >> > >> >> I'd assume we don't need yet another user interface for the LEDs ;) > >> >> AFAICS the PWM subsystem exposes pretty much raw interface in sysfs. > >> >> The PWM LED controllers are already handled in the leds-class API, > >> >> there is the leds_pwm driver (drivers/leds/leds-pwm.c). > >> >> > >> >> I'm adding linux-pwm and linux-leds maintainers at Cc so someone may > >> >> correct me if I got anything wrong. > >> > > >> > The PWM subsystem is most definitely not a good fit for this. The only > >> > thing it provides is a way for other drivers to access a PWM device and > >> > use it for some specific purpose (pwm-backlight, leds-pwm). > >> > > >> > The sysfs support is a convenience for people that needs to use a PWM > >> > in a way for which no driver framework exists, or for which it doesn't > >> > make sense to write a driver. Or for testing. > >> > > >> > > Presumably, what we need is a few enhancements to support in a > >> > > standard way devices like MAX77693, LM3560 or MAX8997. There is > >> > > already a led class driver for the MAX8997 LED controller > >> > > (drivers/leds/leds-max8997.c), but it uses some device-specific sysfs > >> > > attributes. > >> > > > >> > > Thus similar devices are currently being handled by different > >> > > subsystems. The split between the V4L2 Flash and the leds class API > >> > > WRT to Flash LED controller drivers is included in RFC [1], it seems > >> > > still up to date. > >> > > > >> > > >>[1] http://www.spinics.net/lists/linux-leds/msg00899.html > >> > > >> > Perhaps it would make sense for V4L2 to be able to use a LED as exposed > >> > by the LED subsystem and wrap it so that it can be integrated with > >> > V4L2? If functionality is missing from the LED subsystem I suppose that > >> > could be added. > >> > >> The V4L2 flash API supports also xenon flashes, not only LED ones. That > >> said, I agree there's a common subset of functionality most LED flash > >> controllers implement. > >> > >> > If I understand correctly, the V4L2 subsystem uses LEDs as flashes for > >> > camera devices. I can easily imagine that there are devices out there > >> > which provide functionality beyond what a regular LED will provide. So > >> > perhaps for things such as mobile phones, which typically use a plain > >> > LED to illuminate the surroundings, an LED wrapped into something that > >> > emulates the flash functionality could work. But I doubt that the LED > >> > subsystem is a good fit for anything beyond that. > >> > >> I originally thought one way to do this could be to make it as easy as > >> possible to support both APIs in driver which some aregued, to which I > >> agree, is rather poor desing. > >> > >> Does the LED API have a user space interface library like libv4l2? If > >> yes, one option oculd be to implement the wrapper between the V4L2 and > >> LED APIs there so that the applications using the LED API could also > >> access those devices that implement the V4L2 flash API. Torch mode > >> functionality is common between the two right now AFAIU, > >> > >> The V4L2 flash API also provides a way to strobe the flash using an > >> external trigger which typically connected to the sensor (and the user > >> can choose between that and software strobe). I guess that and Xenon > >> flashes aren't currently covered by the LED API. > > > > The issue is that we have a LED API targetted at controlling LEDs, a V4L2 > > flash API targetted at controlling flashes, and hardware devices somewhere > > in the middle that can be used to provide LED or flash function. Merging > > the two APIs on the kernel side, with a compatibility layer for both > > kernel space and user space APIs, might be an idea worth investigating. > > I'm so sorry for jumping in the discussion so late. Some how the > emails from linux-media was archived in my Gmail and I haven't > checkout this for several weeks. > > I agree right now LED API doesn't quite fit for the usage of V4L2 > Flash API. But I'd also like to see a unified API. > > Currently, LED API are exported to user space as sysfs interface, > while V4L2 Flash APIs are like IOCTL and user space library. We also > merged some LED Flash trigger into LED subsystem. My basic idea is > what about creating or expanding the LED Flash trigger driver and > provide a well defined sysfs interface, which can be wrapped into user > space libv4l2. The biggest reason why we're not fond of sysfs-based APIs for media devices is that they can't provide atomicity. There's no way to set multiple parameters in a single operation. We can't get rid of the sysfs LEDs API, but maybe we could have a unified kernel LED/flash subsystem that would provide both a sysfs-based API to ensure compatibility with current userspace software and an ioctl-based API (possibly through V4L2 controls). That way LED/flash devices would be registered with a single subsystem, and the corresponding drivers won't have to care about the API exposed to userspace. That would require a major refactoring of the in- kernel APIs though. -- Regards, Laurent Pinchart -- 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
